Messages in this thread | | | Date | Sun, 03 Feb 2002 16:37:43 -0800 | From | Dan Kegel <> | Subject | Re: [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork performance |
| |
Kev wrote: > > > The /dev/epoll patch is good, but the interface is different enough > > from /dev/poll that ircd would need a new engine_epoll.c anyway. > > (It would look like a cross between engine_devpoll.c and engine_rtsig.c, > > as it would need to be notified by os_linux.c of any EWOULDBLOCK return values. > > Both rtsigs and /dev/epoll only provide 'I just became ready' notification, > > but no 'I'm not ready anymore' notification.) > > I don't understand what it is you're saying here. The ircu server uses > non-blocking sockets, and has since long before EfNet and Undernet branched, > so it already handles EWOULDBLOCK or EAGAIN intelligently, as far as I know.
Right. poll() and Solaris /dev/poll are programmer-friendly; they give you the current readiness status for each socket. ircu handles them fine.
/dev/epoll and Linux 2.4's rtsig feature, on the other hand, are programmer-hostile; they don't tell you which sockets are ready. Instead, they tell you when sockets *become* ready; your only indication that those sockets have become *unready* is when you see an EWOULDBLOCK from them.
If this didn't make any sense, maybe seeing how it's used might help. Look at Poller::clearReadiness() in http://www.kegel.com/dkftpbench/doc/Poller.html#DOC.9.11 or http://www.kegel.com/dkftpbench/dkftpbench-0.38/Poller_sigio.cc and the calls to Poller::clearReadiness() in http://www.kegel.com/dkftpbench/dkftpbench-0.38/ftp_client_pipe.cc
- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |