On Mon, 22 Nov 2004 10:01:42 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>
> > That's no problem except where a given COND can be either signalled or
> > broadcast to.
>
> Such issues need good comment
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
> Parrot's locks will all have wait/signal/broadcast capabilities. We
> should go rename the macros and rejig the code. This may have to wait
Really? I'm not sure I understand what broadcast does on a lock. Are
you talking about something like P5's condpair? If so, why not just
cop that code? Of c
On Fri, 19 Nov 2004 15:35:44 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer wrote:
> > Win32 doesn't require anything else, but I don't think I like this
> > idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what
> > happen
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
