Messages in this thread | | | Date | Sun, 20 Dec 2009 03:26:10 +0300 | From | Nikolai ZHUBR <> | Subject | Re[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
| |