Messages in this thread | | | Date | Tue, 12 Jul 2005 17:25:04 +0200 | From | Paolo Ornati <> | Subject | Re: Lack of Documentation about SA_RESTART... |
| |
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 - 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/
| |