From: Stephen D. <sd...@gm...> - 2006-10-07 15:30:26
|
On 10/7/06, Zoran Vasiljevic <zv...@ar...> wrote: > > On 07.10.2006, at 00:51, Stephen Deasey wrote: > > > 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... > > But there is nothing BAD in doing so? > The only "bad" thing is the effort needed > to abstract kqueue/port_*/poll/etc into a > meaningful API but others have already done > that so we may "borrow" from them, or invent > our own solution. > > I do not consider this a high-priority but > if we want to claim scalability and performance > we should not keep sitting in the grandfathers > old chevy, regarldess how "comfortable" it is... > No, nothing bad. I think it's a great idea! But some of the newer APIs for this are weird because they handle more than socket IO, and we are worried about portability, right? I'm just saying that to get high-performance they may not be strictly necessary. So, if it proves difficult to port to Windows or OSX... doesn't neccessarily matter, they're not going to suffer. But yeah, we should definately move in this direction. |