SIGINFO interrupts connect() with libpthread

[David Xu]

Robert Watson wrote:

>
>
> On Fri, 7 Oct 2005, Daniel Eischen wrote:
>
>> On Thu, 6 Oct 2005, Robert Watson wrote:
>>
>>> I was writing test tools yesterday, and was a bit surprised to find 
>>> that hitting ctrl-T interrupts connect() for applications linked 
>>> against libpthread().  I wrote a simple test tool and found that 
>>> this is not the case for any of the other thread libraries (which 
>>> seems correct to me). Test tool attached:
>>
>>
>> This isn't a problem with libpthread.  If you install a signal 
>> handler for SIGINFO in your application with sa_flags = SA_RESTART, 
>> it gets interrupted even when just linked with libc.
>
>
> Unlike, say, an I/O operation, the notion of restarting a connect() 
> system call is fairly fraught with peril.  Normally, attempts to call 
> connect() on a socket that is already in the process of connecting 
> will return EALREADY, since you don't want to further frob the 
> protocol state machine. A bit of googling suggests that Stephens talks 
> about this in some detail, pointing out that in the EINTR case, the 
> application will really need to select() for the socket becoming 
> writable in order to wait for the connection attempt to finish (or 
> fail).  While a bit awkward for the application, it appears these are 
> not uncommon semantics for the system call, and suggest the perils of 
> using blocking I/O with signals are significant.  Unfortunately, the 
> problem with this libpthread feature is that, unlike our other thread 
> libraries, it exposes the application to this peril even if the 
> application itself doesn't actively use signals.
>
> Is your suggestion that connect() should detect an attempt to connect 
> to the same host and "continue where it left off"?  POSIX tells us 
> that EALREADY should be returned if that is attempted:
>
> [EALREADY]
>     A connection request is already in progress for the specified socket.
>
Unfortunately, it is not stable to use errno, problem is many programmers do
not preserve errno in signal handler,  so after the signal handler did a 
failure
syscall, the errno must not be EALREADY, although I know libpthread has
code to protect errno in signal handler, but not other thread libraries, 
this
is also not a portable feature. :-)

David Xu