Re: Lack of Documentation about SA_RESTART...

[Paolo Ornati <ornati@fastwebnet.it>]

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