apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject apr_pollset multithread semantics?
Date Mon, 18 Jul 2005 02:20:10 GMT
For implementations of apr_pollset that support the  
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?

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.

Would a couple of volunteers be willing to run the attached test  
program on
Linux 2.6 (or a patched 2.4) with epoll and non-Apple BSD versions  
with kqueue
to confirm whether these platforms exhibit the same semantics?

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


View raw message