Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> 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)
You are already in the POSIX specific part.
1) During configure parrot includes platform code from files located in
config/gen/platform/*/
2) if a platform doesn't have an implementation the ../generic/
directory is used.
3) $ find config -name threads.h
config/gen/platform/generic/threads.h
So there is no win32/threads.h (yet ;)
If the implementation needs some additional libraries, the hints/* are
consulted e.g.
config/init/hints/linux.pl: $libs .= ' -lpthread';
>> 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...
We'll see. But as Parrot's IO system is gonna be asynchronous in core, I
doubt that we'll support it.
>> 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?
The main reason for the global event queue isn't message passing. The
reason is POSIX signals. Basically you aren't allowed to do anything
serious in a signal handler, especially you aren't allowed to broadcast
a condition or something.
So I came up with that experimental code of one thread doing signals.
> 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.
Yes. The AIO library is doing that anyway i.e. utilizing a thread pool
for IO operations.
>> 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?
Dan did post a series of documents to the list some time ago. Sorry I'be
no exact subject, but with relevant keywords like "events" you should
find it.
> GNS
leo
