apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: apr_poll inconsistency
Date Fri, 26 Jan 2001 17:23:43 GMT
On Fri, 26 Jan 2001 07:42:10 -0800 (PST), rbb@covalent.net wrote:

>My own opinion Brian, is to choose an implementation you like, and make
>that a standard.

I prefer the more diplomatic approach & allow others to comment first
before I go changing things that may affect them. Someone might have a good
reason why the other way is better.

>If that means we clear the apr_poolfd_t, then cool, if
>not, that's cool too.  If you make the choice, and don't want to change
>on Unix, I'll do it.

I should be able to handle it, but thanks anyway (yes, I have a unix box

>On Fri, 26 Jan 2001, Brian Havard wrote:
>> I've noticed that some implementations of apr_poll clear the apr_pollfd_t
>> they're given, requiring reapplication of apr_add_poll_socket()s, and some
>> don't.
>> Apart from being inconsistent, it's a problem for me because the
>> implementation I wrote for OS/2 doesn't clear the list but doesn't prevent
>> duplicates either so when an app re-adds after an apr_poll() it results in
>> duplicates in the list (it's just an array of descriptors). ApacheBench
>> (ab) on OS/2 is currently broken because of this but I'm not sure what the
>> correct fix is.
>> I'd like to see consistent behaviour from apr_poll() on all platforms but
>> which? My own preference is to not clear the list & therefore not require
>> repeated apr_add_poll_socket() calls. This would require the select based
>> implementations to copy their fd_sets before calling select().
>> Thoughts?

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |

View raw message