Re: Lack of Documentation about SA_RESTART...

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jul 12, 2005 at 10:38:11AM +0200, Paolo Ornati wrote:
> The particular case you analized (blocking connect interrupted by a
> SA_RESTART signal) is interesting... and since SUSV3 says
> 	"but the connection request shall not be aborted, and the connection
> 	shall be established asynchronously" (with select() or poll()...)
> both for EINPROGRESS and EINTR, I think it's quite stupit to
> automatically restart it and then return EALREADY.
> 
> 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.  But, the paranoid application writer should check
for EINTR being returned from a non-blocking connect, since that is
the what the currently deployed Linux kernels will do right now in
this rare case.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/