apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: apr_pollset multithread semantics?
Date Mon, 18 Jul 2005 12:41:21 GMT
On Sun, Jul 17, 2005 at 07:20:10PM -0700, Brian Pane wrote:
> For implementations of apr_pollset that support the 
> APR_POLLSET_THREADSAFE option to apr_pollset_create(), what's supposed 
> to happen if thread T1 adds a descriptor to a pollset while thread T2 
> is blocked in a call to apr_pollset_poll() for the same pollset?

I had actually presumed it would be OK to leave the behaviour as not 
explicitly defined, but I can see it would certainly be useful to be 
able to rely on your (A) case below if that can actually be guaranteed.

> Because the comments in apr_poll.h don't specify the semantics in this 
> scenario, an implementation could potentially work in any of the 
> following ways:
> 
>   A. The current apr_pollset_poll() call automatically includes the 
> newly added descriptor in the set of descriptors it's watching?
>   B. The current apr_pollset_poll() call returns immediately with  
> something like EINTR.
>   C. The current apr_pollset_poll() call ignores the newly added 
> descriptor.  Only on the next call to apr_pollset_poll() is the 
> descriptor actually included in the polling operation.
> 
> I just wrote a test program to determine that the kqueue-based 
> implementation of apr_pollset uses option A...at least on Darwin 8.x.

epoll also appears to behave like (A).  (testing the FC3 2.6.11-based 
kernel)

> If both the kqueue and epoll implementations match option A or B, I 
> propose making this a documented part of the semantics of 
> apr_pollset_*, at least for the thread-safe implementations.

Sounds good, though the (B) behaviour would be a little surprising.

Regards,

joe

Mime
View raw message