lkml.org 
[lkml]   [2009]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe[3]: epoll'ing tcp sockets for reading
Sunday, December 20, 2009, 1:56:22 AM, Davide Libenzi wrote:
[trim]
> The kernel cannot make decisions based on something whose knowledge is
> userspace bound.
I didn't mean that. I just meant it would be usefull to let the caller
of epoll know also the size of data related to specific EPOLLIN event in
some "atomic" manner immediately, because the kernel probably knows this
size already.
The same thing can approximately be "emulated" by requesting FIOREAD for
all EPOLLIN-ready sockets just after epoll returns, before any other work.
It just would look not very elegant IMHO.

> What you define as "abstract/imprecise/overcomplicated" are simply
> decisions that you, as implementor of the upper layer protocol, have to
> take in order to implement your userspace code.
> And I, personally, see nothing even close to be defined complicated in
> such code.
> Whenever you're asking for an abstraction/API to implement a kind
> of software which exist in large quantities on a system, you've got to ask
> yourself how relevant such abstraction is at the end, if all the existing
> software have done w/out it.
Ok, maybe that's what I should have asked at the first place. What would
you recommend as a reference implementation showing clean, efficient,
fail-safe usage of epoll with sockets?
Actually I've been googling for about 2 weeks to find some, but the results
are rather scarce and dubious.

Thank you!

Nikolai ZHUBR


> - Davide




\
 
 \ /
  Last update: 2009-12-20 01:25    [W:0.053 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site