apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Solaris pollset_add weirdness
Date Mon, 18 Jul 2011 19:31:23 GMT
On 07/18/2011 08:55 PM, Jeff Trawick wrote:
> On Mon, Jul 18, 2011 at 8:23 AM, Mladen Turk<mturk@apache.org>  wrote:
>> Hi,
>> Anyone can explain the purpose of add_ring in Solaris
>> port.c and its usage during pollset_add/pollset_wait
> The purpose seems to be avoiding the wasted port_associate() call when
> an event is triggered then removed by the app from the apr pollset
> prior to the next call to apr_pollset_poll().  I'm not aware of a
> functional requirement that it work that way.

Don't think that's the case.
It's never removed from the add_ring so next poll will always
add that, and its the same amount of syscalls.

> Performance will be lower (two extra syscalls -- associate and
> disassociate -- when app is going to remove the descriptor from the
> pollset due to the event which just occurred).  No idea here how
> important that is.

Don't think I follow you here. If associate fails during add, it
won't get added. Same thing if pollset is inside poll call.

> What is the overall consistency/lack thereof in handling your case
> (adding shutdown socket to pollset) across epoll, poll-or-select, and
> event ports?

Add 5 sockets with first being shutdown/faulty/whatever.
All other implementations will fail adding the first one, and add 4 remaining.
Solaris add version will report OK for all of them.
Then the next call to poll will fail on first one and not add 4 remaining
sitting in the queue until you call poll again.
And of course all that behaves differently if it happens that the other
thread is executing the poll, in which case (amazingly) solaris implementation
behaves like all other platforms.

So the user algorithm that polls the sockets needs to
ifdef SOLARIS and act differently which is opposite of what APR is.


View raw message