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
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
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
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
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
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
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)
