Solaris pollset_add weirdness

[Mladen Turk <mt...@apache.org>]

Hi,

Anyone can explain the purpose of add_ring in Solaris
port.c and its usage during pollset_add/pollset_wait


Current behavior is different from other implementations
in such way that adding faulty sockets (e.g. shutdown)
to the pollset behaves randomly depending on the state at
which currently the pollset is.

a.) If the pollset is currently in the pollset_poll
     state adding fault socket will fail.
b.) If the pollset is NOT in the poll call, the socket
     is added to the add_ring and OK is returned !?
     Next call to poll calls port_associate for that socket
     and if one fails, all other in the queue are skipped.
     Fault cause pollset_add returned OK for all of them!
     Also the return error is for poll_add not for poll.

Any technical reason why we can't call port_associate
always during pollset_add instead just if its executing
port_getn? I mean I would expect at least otherwise, but
it seems port_getn and port_associate can be called
concurrently, so cannot get the need for an additional
queue.



Cheers
-- 
^TM

Re: Solaris pollset_add weirdness

[Jeff Trawick <tr...@gmail.com>]

On Mon, Jul 18, 2011 at 3:31 PM, Mladen Turk <mt...@apache.org> wrote:

apologies for not following up yet; I'll try to spend some time real soon

(I'm not necessarily opposed to the change, but I clearly need to
understand the implications a bit better as I realize I was a bit
confused)

Re: Solaris pollset_add weirdness

[Mladen Turk <mt...@apache.org>]

On 07/18/2011 08:55 PM, Jeff Trawick wrote:
> On Mon, Jul 18, 2011 at 8:23 AM, Mladen Turk<mt...@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.



Regards
-- 
^TM

Re: Solaris pollset_add weirdness

[Jeff Trawick <tr...@gmail.com>]

On Mon, Jul 18, 2011 at 8:23 AM, Mladen Turk <mt...@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.

> Current behavior is different from other implementations
> in such way that adding faulty sockets (e.g. shutdown)
> to the pollset behaves randomly depending on the state at
> which currently the pollset is.
>
> a.) If the pollset is currently in the pollset_poll
>    state adding fault socket will fail.
> b.) If the pollset is NOT in the poll call, the socket
>    is added to the add_ring and OK is returned !?

Legacy implementations (select()/poll()) differ from port/epoll/kqueue
on these points too, right?

>    Next call to poll calls port_associate for that socket
>    and if one fails, all other in the queue are skipped.

but not lost; if apr_pollset_poll() is called again, it will pick up
with the remainder and add them, right?

>    Fault cause pollset_add returned OK for all of them!
>    Also the return error is for poll_add not for poll.
>
> Any technical reason why we can't call port_associate
> always during pollset_add instead just if its executing
> port_getn? I mean I would expect at least otherwise, but
> it seems port_getn and port_associate can be called
> concurrently, so cannot get the need for an additional
> queue.

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.

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