> > 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 I'm reading Poller_sigio::waitForEvents correctly, the rtsig stuff at least tries to return a list of which sockets have become ready, and your implementation falls back to some other interface when the signal queue overflows. It also seems to extract what state the socket's in at that point. If that's true, I confess I can't quite see your point even still. Once the event is generated, ircd should read or write as much as it can, then not pay any attention to the socket until readiness is again signaled by the generation of an event. Sorry if I'm being dense here... -- Kevin L. Mitchell <[EMAIL PROTECTED]>