Re: Lack of Documentation about SA_RESTART...

Paolo Ornati
2005-07-12T15:26:04Z

On Tue, 12 Jul 2005 08:04:56 -0400
Theodore Ts'o <tytso@mit.edu> wrote:

> >
> > The logically correct behaviur with blocking connect interrupted and
> > then restarted should be to continue the blocking wait... IHMO.
>
> I was looking at what happened with a *non-blocking* connect
> interrupted by an SA_RESTART signal. Since it is non-blocking, it
> will never continue with the wait. The only question is whether it
> should return with an EINTR (which is what it currently does) or
> return with whatever error code it would have returned if the signal
> had not been delievered in the first place. We currently do the
> former; a close reading of the spec seems the require the latter.
> Fortunately this is a pretty narrow race condition since the chances
> of a signal being delivered right in the middle of a non-blocking
> connect are small.

Hmmm... no, no. A connect() on non-blocking socket will NEVER return
EINTR. SUSV3 and Linux code agree.

A syscall isn't magically interrupted if a signal arrives... it's the
syscall that must check for pending signals and do the proper action
(usually it will return with -EINTR or -ERESTARTSYS).

A connect() on a blocking socket is something like this (very
approssimative):

1) code to activate the connection
2) sleep waiting for something (connection ready / signal received...)
3) if connection is ready then return 0, else if there are pending
signals return -ERESTARTSYS

With non-blocking socket the syscall never sleeps, and never checks for
pending signals.

Look at "net/ipv4/af_inet.c": in particular at "net_wait_for_connect"
and its usage in "inet_stream_connect".

--
Paolo Ornati
Linux 2.6.12.2 on x86_64