Re[3]: epoll'ing tcp sockets for reading

[Nikolai ZHUBR <zhubr@mail.ru>]

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