I was just browsing the Parrot source, and noticed that the threading implementation is a bit Unix/pthread-centric. For example:
* COND_WAIT takes a mutex because that's how pthreads works, but Win32 condition variables (called "events") are kernel objects that do not require any other object to be associated with them. I think this could be cleaned up with further abstraction. * CLEANUP_PUSH doesn't have any Win32 analog that I know of, although it's not clear why this might be needed for Parrot anyway. Right now it just looks like it's used to prevent threads from abandoning a mutex, which isn't a problem with Win32. The big issue, though, is with the IO thread. On NT the IO is already async and there are no signals (Ctrl+C is handled with a callback), so each interpreter thread should just be able to handle all of this in the check_events functions. That is, AIO and timers allow you to specify a completion callback (asynchronous procedure call) that gets executed once you tell the OS that you're ready for them (e.g. via Sleep), so the whole event dispatching system may not even be necessary. Win9x doesn't have async IO on files, so it still might require separate threads to do IOs. Note that the Windows message queue does not really get involved here (unless you want it to), as it is mainly for threads that have UIs or use COM/DDE. Anyway, it seems to me that all this event/IO stuff needs significantly more abstraction in order to prevent it from becoming a hacked-up mess of #ifdefs. However, I couldn't find any docs on this, so I just guessed how it all works based on the source. Feel free to whack me with a cluestick if I'm wrong about anything. GNS
