[Libvir] take 2 [Re: write(2) may write less than the total requested

[Jim Paris]

Jim Meyering wrote:
> It *could* perform that test, but I think it is slightly more
> maintainable (no duplication of that potentially nontrivial expression)
> and just as correct to check only "ret < 0".

Not having the duplicated expression is certainly good, if it's
correct to do so (and it seems you're right).

> > but it's still possible for it to return less than requested
> > if write() returns 0 (eof?).
> 
> Really?  How?  EOF is relevant to read, but not to write(2).
> 
> As I see it, calling safewrite can have only two outcomes:
>   - return -1 to indicate failure
>   - return the requested byte count (arg #3, count, which is non-negative)
> The only way safewrite can return 0 is if its "count" argument is also 0,
> and that's not a failure.  This is because write itself can return 0 only
> if its count is also 0.

Hmm, I was thinking write might return 0 for closed pipes and similar
but you're right, that's different from EOF and should return error.

http://www.opengroup.org/onlinepubs/000095399/functions/write.html
says:
  Where this volume of IEEE Std 1003.1-2001 requires -1 to be returned
  and errno set to [EAGAIN], most historical implementations return
  zero (with the O_NDELAY flag set, which is the historical
  predecessor of O_NONBLOCK, but is not itself in this volume of IEEE
  Std 1003.1-2001). The error indications in this volume of IEEE Std
  1003.1-2001 were chosen so that an application can distinguish these
  cases from end-of-file.
so we're safe here.

It does bring up the point that safewrite() doesn't handle EAGAIN and
might not be appropriate for non-blocking fds.  The sigwrite pipe is
non-blocking.  At quick glance, the qemud fds might be that way too?

It also makes me notice that we have 3 *SetNonBlock functions, two
with the same name even...

-jim