Kev wrote: > > > > 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...
If you actually do read or write *until an EWOULDBLOCK*, no problem. If your code has a path where it fails to do so, it will get stuck, as no further readiness events will be forthcoming. That's all. - Dan
