On 10/6/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 06.10.2006, at 23:41, Stephen Deasey wrote: > > What's the goal? We can certainly abstract socket event IO, with > poll() as a fallback. But some of the interfaces you mentioned here > can handle waiting on other things, e.g. signals. Is this what you > want? At the moment only as replacement for poll as kqueue or solaris port_* are way more scalable.
That's not necessarily the case. This only matters when you have many sockets open simultaneously, where 'many' would be in the thousands, or thereabouts. poll() is slow with many sockets because for each spin the entire array of sockets must be checked, even if poll() woke up because just one of them has an event. It's the scanning of the array which is the bottleneck. But there are techniques you can use to work around this. For example, the old patch I posted to the AOLserver bug tracker which accepts multiple new sockets on every spin. You basically drain the listen backlog. The tests in the paper about this show that poll() based implementation became just as scalable as the fancier event notification mechanisms. Something else we can try is a Linux and BSD socket option which causes a listening socket to only generate a readable event when a new socket arrives *and* there is data to read. Usually, you get one when a new connection arrives, you accept(), then you poll() again for data, then you read it. Anyway, I'm all for using epoll() and so on, I think it's a great idea. But it's probably not going to be the performance hack of the century...
