Jaromir Dolecek wrote:
> marius aamodt eriksen wrote:
> > in order to be able to preserve consistent semantics across poll,
> > select, and kqueue (EVFILT_READ), i propose the following change: on
> > EVFILT_READ, add an fflag NOTE_EOF which will return when the file
> > pointer *is* at the end of the file (effectively always returning on
> > EVFILT_READ, but setting the NOTE_EOF flag when it is at the end).
> >
> > specifically, this allows libevent[1] to behave consistently across
> > underlying polling infrastructures (this has become a practical
> > issue).
> 
> I'm not sure I understand what is the exact issue.
> 
> Why would this be necessary or what does this exactly solve? AFAIK
> poll() doesn't set any flags in this case neither, so I don't
> see how this is inconsistent.
> 
> BTW, shouldn't the EOF flag be cleared when the file is extended?

It solves the half-close-on-socket issue which occurs on an HTTP/1.0
request or an HTTP/1.1 non-pipelined/terminal request that occurs on
most HTTP connections as a result of the client closing their side
of the socket connection, but the server being expected to provide a
response to the request on the same socket.

You need this to be able to distinguish, after getting an EOF, if you
need to provide a response to the request, or you need to drop it,
based on additional processing you choose to do in your application.

Doing it this way saves you 33%, 50%, or 66% of the required system
calls to detect the edge conditions, depending on your I/O model and
when they hit.

It is useful for HTTP servers, HTTP Proxy servers, L7 load balancers,
load balancers that implement Direct Server Return for requests, and
in a number of other common cases having to do with networking (e.g.
transcoding proxies for cell phones or other users requiring it, FTP
control vs. data channels in the non-passive case, ssh/rcmd/etc., as
just a couple of select examples).

I rather expect that it would be singularly useless for socketpair(),
pipe(), named pipe (FIFO), or file operations, but that's not what we
are talking about when we talk about event libraries that deal with
input sources/sinks.

-- Terry