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

[Davide Libenzi]

On Sun, 20 Dec 2009, Nikolai ZHUBR wrote:

> 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.

No such a thing of "atomic matter", since by the time you read the event, 
more data might have come. It's just flawed, you see that?



> > 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.

My reference was not epoll in particular, but more in general all the 
network/server software that have been written using select/poll and the 
current POSIX APIs, w/out the need of knowing how much data there was on 
the link.



- Davide


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/