Unix domain datagram based messaging
Volker Lendecke
Volker.Lendecke at SerNet.DE
Thu Apr 10 12:46:58 MDT 2014
On Thu, Apr 10, 2014 at 10:05:31AM -0700, Jeremy Allison wrote:
> In fact the only thing I can see that
> might be an issue here is how does
> unix_dgram_recv_handler() handle
> a it if we get a geniune error that
> causes recv() to return -1. Won't it
> keep getting called ? I'll do some
> more digging here..
Yep, that's what I thought as well. ENOMEM is one that might
hit us like the Solaris socket problem, but there retry
should not hurt and might be the right thing. The only thing
I can really imagine to happen here is that someone else
closes the socket behind our back, but then we deserve a
100% loop, right? :-)
If I look at the other stuff that can happen according to
susv4, most of them should retry fine.
> The send() in unix_dgram_send_job()
> should be protected by a:
>
> do {
> msg->sent = send(msg->sock, msg->buf, msg->buflen, 0);
> } while (msg->sent == -1 && errno == EINTR);
>
> loop as it's only ever called as a
> pthread_add_job job, so we never return
> to the main loop here (we *are* the main
> loop :-).
Yep, indeed.
> The code in unix_dgram_send() already
> has the case we need, I think you
> just need to change:
>
> + if (errno != EWOULDBLOCK) {
> + return errno;
> + }
>
> to:
>
> + if (errno != EWOULDBLOCK && errno != EAGAIN && errno != EINTR) {
> + return errno;
> + }
>
> in that function and it's ok !
Agreed.
New patchset pending. I'll send it once I figured out more
of the socket and lockfile leak.
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
More information about the samba-technical
mailing list