alternatively, if serializing was implemented by a standard blitzmax module, this could be used to pass copies of practically *any* object to the threads (with the only drawback that you'd have to be very carefull no to pass huge graphes of objects this way, as serializinf is recursive).
I kind of like that idea. It seems like you might end up requiring a very simple structure like I defined as TThreadEvent, but if we used generic serializing functions it would be possible to use any class as long as it could be serialized (for instance, object have to provide their own implementation of serialization in MFC).
Like some are saying, I don't think the core language *can* be thread safe. If two threads try to print to the same console, what happens? Well, the app crashes. Period. I really honestly don't have a problem with that. If I need two threads to output text, they will send a message to the main loop and it will do the output. We can't isolate programmers from their own stupidity or lack of knowledge of thread-safe operations, though my system goes a long way in doing that I think.
Threads don't communicate.
They do their task and end, giving you the result.
While that's certainly true of some threads, it isn't always the case. Network threads often will stay running for the entire application lifetime, for instance, to handle messages coming and going.
Your idea is more of a thing for which pub.freeprocess, TProcess.pipe and stdinStream / stdoutstream are used for.
Uh, no. While this could be partially implemented using those libraries, that does not in any way replace the utility of having actual threads within the same app. The only way those could be used as-is to create anything similar would be to have multiple actual processes simulating threads, which is quite expensive on most platforms.
Winni, XBase++ sounds interesting. I'm going to look it up. I'd really like to see this kind of thing in BM.
Mark,
Well if you do come to that I'd be very keen to see it. I'll be the first to do testing if you like. I wonder if something like this might be good as a partial solution, if the implementation would be faster than making the GC thread safe.