On Sun, 21 Nov 2004 10:09:06 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Currently we have COND only for the task queues. But if we need
> conditions in other places, QUEUE_CONDITION is misleading.
> So the current se
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> The problem is a different one: the COND_INIT macro just passes a
> condition location, the mutex is created in a second step, which isn't
> nee
> [ long win32 proposal ]
>
> I've to read through that some more times.
OK; let me know if you have any questions on how the Win32 stuff
works. I tried to explain things that are unlike POSIX, but of course
it makes sense to me.
> Do you alread have ideas for a common API, or where to split the
> >> 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 p
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 object
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 b
