Re: [Xen-devel] [PATCH 2/2] libxl: Cope with pipes which signal POLLHUP|POLLIN on read eof

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-04-08 at 12:05 +0100, Wei Liu wrote:
> On Tue, Apr 07, 2015 at 02:05:28PM +0100, Ian Jackson wrote:
> > Some operating systems (including Linux and FreeBSD[1]) signal not
> > (only) POLLIN when a reading pipe reaches EOF, but POLLHUP (with or
> > without POLLIN).  This is permitted[2].  The implications are that in
> > the general case it is not possible to determine whether POLLHUP
> > indicates an error or simply eof without attempting a read.
> > 
> > Datacopiers mishandle this, because they always treat POLLHUP
> > exceptionally (either reporting it via callback_pollhup, or treating
> > it as an error).  datacopiers reading from pipes on such OSs can fail
> > (perhaps leaving some data unprocessed) rather than completing
> > successfully.
> > 
> > [1] http://www.greenend.org.uk/rjk/tech/poll.html
> > [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
> > 
> > Distinguishing POLLHUP is needed for pty fds, but most callers in
> > libxl do not care about POLLHUP except as an error or eof condition.
> > 
> > So change the datacopier semantics so that if callback_pollhup is not
> > specified we treat POLLHUP almost like POLLIN.  The difference is that
> > if we get HUP from poll, but EWOULDBLOCK from read, we must signal an
> > error ratehr than attempting the read again.
> > 
> > This fixes the problem which 7e9ec50b0535 was aimed at.
> > 
> > Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
> > CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > CC: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> > CC: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> > CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> 
> The code matches documents and commit log so:
> 
> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

Likewise, so I applied, doing s/ratehr/rather/ on the commit message.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel