Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> 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.
Not quite. COND_WAIT takes an opaque type defined by the platform, that
happens to be a mutex for the pthreads based implementation.
> * 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.
Yes. And it'll very likely go away. But anyway - it's a define by the
platform. So you can define it being a noop for 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.
Not all. We need to do check_events() for e.g. message passing too.
> .... Win9x doesn't have async IO on files, so it still might
> require separate threads to do IOs.
I'm not sure, if we even should support Win9{8,5}.
> 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.
Yep. The system-specific stuff should be split into platform files. A
common Parrot API then talks to platform code.
> ...However, I couldn't find any docs on this,
> so I just guessed how it all works based on the source.
The current state of the implemented pthread model is summarized in
docs/dev/events.pod.
> ... Feel free to
> whack me with a cluestick if I'm wrong about anything.
Au contraire. Your analysis is precise. Do you like to take a shot at a
Win32 threads/event model? So we could figure out the necessary
splitting of API/implementation.
> GNS
leo
