Re: [Xen-devel] [PATCH v7 01/14] libxl: Enhance libxl__sendmsg_fds to deal with EINTR and EWOULDBLOCK

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Fri, Dec 21, 2018 at 02:30:05PM +0000, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v7 01/14] libxl: Enhance libxl__sendmsg_fds to 
> deal with EINTR and EWOULDBLOCK"):
> > This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
> > EINTR error.
> > 
> > This patch also allow a caller of libxl__sendmsg_fds to deal with
> > EWOULDBLOCK. The function now requires to send only 1 byte of data so
> > that when dealing with non-blocking fds a EWOULDBLOCK error would mean
> > that the fds haven't been sent yet. Current caller already send only 1
> > byte.
> 
> Even with a blocking fd, sendmsg may in principle report a short
> write.  (So the commit message should talk about short writes in
> general.)

I have rewrite the commit message like this:

This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
EINTR error and return an error on short writes.

This patch allow a caller of libxl__sendmsg_fds to deal with EWOULDBLOCK
and short writes. The function now requires to send only 1 byte of data
so that when dealing with non-blocking fds a EWOULDBLOCK error would
mean that the fds haven't been sent yet. Current caller already send
only 1 byte.


> > Notes:
> >     v7:
> >         always assert datalen == 1, but only fail when sendmsg haven't send
> >         everything (r != datalen)
> >         check sendmsg return value on success as well (check for short 
> > write)
> 
> Rather than having a function which takes an argument which
> mandatorily takes the value 1, how about simply deleting that
> argument ?

I'll add a new patch to do that at the end of the series.

> You can do that in a followup patch if you like.  In the meantime:
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel