On 03/16/2011 19:20, Garrett Cooper wrote:
So yes, EINTR not being allowed is by design and this backs up what
davidxu@ is stating above. Our manpage just doesn't explicitly call
this requirement out, unlike a Linux manpage I dug up and the
OpenGroup manpage.
I apologize for keeping
On 02/27/2011 18:00, David Xu wrote:
I think in normal case, pthread_cond_signal will wake up one thread,
but other events for example, UNIX signal and fork() may interrupt
a thread sleeping in kernel, and cause pthread_cond_wait to return
to userland, this is called spurious wakeup, and other
On 2011/03/16 23:23, Yuri wrote:
On 02/27/2011 18:00, David Xu wrote:
I think in normal case, pthread_cond_signal will wake up one thread,
but other events for example, UNIX signal and fork() may interrupt
a thread sleeping in kernel, and cause pthread_cond_wait to return
to userland, this is
On Wed, Mar 16, 2011 at 6:54 PM, David Xu davi...@freebsd.org wrote:
On 2011/03/16 23:23, Yuri wrote:
On 02/27/2011 18:00, David Xu wrote:
I think in normal case, pthread_cond_signal will wake up one thread,
but other events for example, UNIX signal and fork() may interrupt
a thread sleeping
On 28.02.11 2:41, Pieter de Goeje wrote:
pthread_cond_signal() can indeed wake up more than one thread. That's why you
should always wrap pthread_cond_wait() in a loop. For example a blocking
queue could be implemented like this (pseudo code):
Thank you. Now its clear that POSIX allows
On Monday 28 February 2011 16:08:32 Yuri wrote:
On 28.02.11 2:41, Pieter de Goeje wrote:
pthread_cond_signal() can indeed wake up more than one thread. That's why
you should always wrap pthread_cond_wait() in a loop. For example a
blocking
queue could be implemented like this (pseudo
On FreeBSD-8.1 this page says:
The pthread_cond_signal() function unblocks one thread waiting for the
condition variable cond.
On Linux it says:
The /pthread_cond_signal/() function shall unblock at least one of the
threads that are blocked on the specified condition variable /cond/ (if
any
Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.
Also I want to add that I came to this question while observing behavior
consistent with multiple wakeup on FreeBSD-8.1. The heavily
multi-threaded code that assumes that only one thread can be woken up by
one
On 2011/02/28 05:26, Yuri wrote:
Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.
Also I want to add that I came to this question while observing behavior
consistent with multiple wakeup on FreeBSD-8.1. The heavily
multi-threaded code that assumes that only one thread can
On Feb 27, 2011, at 4:26 PM, Yuri y...@rawbw.com wrote:
Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.
Also I want to add that I came to this question while observing behavior
consistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded
code that
On Sunday 27 February 2011 22:26:18 Yuri wrote:
Also I want to add that I came to this question while observing behavior
consistent with multiple wakeup on FreeBSD-8.1. The heavily
multi-threaded code that assumes that only one thread can be woken up by
one pthread_cond_signal call crashes,
11 matches
Mail list logo
