On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> > * 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.
It should, but it doesn't. Here's the definition:
# define COND_WAIT(c,m) pthread_cond_wait(&c, &m)
It explicitly takes a condition and a mutex, while it should just be
passed a Parrot_cond (or something like that):
typedef struct {
#ifdef pthreads
pthread_mutex_t m;
pthread_cond_t c;
#elseif Win32
HANDLE h;
#endif
} Parrot_cond;
> > 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}.
I'd be happy with simply implementing Win9x as a non-threaded
platform. Of course, hopefully nobody will even ask...
> > 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.
Thanks, I didn't see that. My problem isn't with what the
implementation does, though -- it's that I don't understand the
rationale. I can understand why there would need to be a global event
thread (timers, GC, DoD), but why would passing a message from one
thread to another need to be serialized through a global event queue?
And as for IO, I see the obvious advantages of performing synchronous
IO functions in a separate thread to make them asynchronous, but that
sounds like the job of a worker thread pool. There are many ways to
implement this, but serializing them all through one queue sounds like
a bottleneck to me.
> 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.
OK. I think I need to have a better understanding on what events
actually are, though. Who sends them? What do they mean? Which signals
do we actually care about? What are notifications? How will AIO
actually be handled? You know, that sort of thing... Maybe there
should be a PDD for it?
GNS
