On 07/18/2011 08:55 PM, Jeff Trawick wrote:
On Mon, Jul 18, 2011 at 8:23 AM, Mladen Turk<[email protected]> 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.
Regards
--
^TM
