On Tue, 12 Jul 2005 08:04:56 -0400
Theodore Ts'o <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
