Re: COND macros

2004-11-22 Thread Gabe Schaffer
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 comments in source code. Does that imply that we > nee

Re: COND macros

2004-11-22 Thread Leopold Toetsch
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 comments in source code. Does that imply that we need: COND_INIT_SIGNAL COND_INIT_BROADCAST > GNS leo

Re: COND macros

2004-11-21 Thread Gabe Schaffer
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 set of macros for existing stuff

Re: COND macros

2004-11-21 Thread Leopold Toetsch
Gabe Schaffer <[EMAIL PROTECTED]> wrote: > I think that maybe what we need is a MUTEX, a CONDITION, and a > QUEUE_CONDITION. The QUEUE_CONDITION would always contain a mutex and > a condition, while the CONDITION would have a c,m for POSIX and just c > for Win32. Currently we have COND only for t

Re: COND macros (was: Threads, events, Win32, etc.)

2004-11-20 Thread Gabe Schaffer
> 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

Re: COND macros

2004-11-20 Thread Gabe Schaffer
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 > > happens when some code goes to LOCK(m)? It would work

Re: COND macros

2004-11-19 Thread Leopold Toetsch
Gabe Schaffer wrote: 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 needed for windows. O

Re: COND macros (was: Threads, events, Win32, etc.)

2004-11-19 Thread Dan Sugalski
At 8:42 AM -0500 11/19/04, Gabe Schaffer wrote: 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, whi

Re: COND macros (was: Threads, events, Win32, etc.)

2004-11-19 Thread Gabe Schaffer
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 > needed for windows. OTOH a mutex a

COND macros (was: Threads, events, Win32, etc.)

2004-11-17 Thread Leopold Toetsch
Gabe Schaffer <[EMAIL PROTECTED]> wrote: >> >> 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)