Unix domain datagram based messaging

Jeremy Allison jra at samba.org
Thu Apr 10 09:52:05 MDT 2014

On Thu, Apr 10, 2014 at 01:24:48PM +0200, Stefan (metze) Metzmacher wrote:
> Am 10.04.2014 12:26, schrieb Volker Lendecke:
> > On Wed, Apr 09, 2014 at 02:28:19PM -0700, Jeremy Allison wrote:
> >> It's removing most of our signal issues,
> >> which is great ! However, at least within
> >> smbd we still have to handle slow system
> >> calls returning -1,EINTR if we get hit
> >> by POSIX realtime signals from the leases
> >> (of course due to this patchset this should
> >> now be *extremely* rare :-)
> >>
> >> So shouldn't:
> >>
> >> recv() in unix_dgram_recv_handler()
> >> connect() in unix_dgram_send_queue_init()
> >> send() in unix_dgram_send_job()
> >> sendmsg() in unix_dgram_send()
> >>
> >> in this patchset be changed to handle -1,EINTR with
> >> an immediate retry ?
> > 
> > I'm always a bit reluctant to add these unconditional loops,
> > because it postpones signal handling unnecessarily and makes
> > Ctrl-C not work as expected. For the syscalls that are
> > called from the central event loop, shouldn't we try to make
> > sure that we handle EINTR in the sense that the call just
> > did not happen? The event loop should come back to us
> > immediately again, the socket should still be ready as seen
> > by poll. You're right, I have not thought about this yet at
> > all, so some modifications are required. I just don't know
> > if the hard retry is the right thing in this very lowlevel
> > library.

Yes, that happens correctly within tevent. A signal
causes us to just retry after going through the
main loop.

However, on first glance I wasn't sure if
your changes treated -1 as returning an
error (I think they did but I'll check again
to be sure).

> Yep, I think we can just handle it like EAGAIN.

Yes, just returning to the main loop to retry
would be the cleanest solution.

The reason I posted the patch for the dnssock
functions is that they explicitly treat -1,EINTR
as an error return and fail the call, which I
think is the wrong thing to do here.


More information about the samba-technical mailing list