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. > 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?
