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