>> If the connect() system call is interrupted by a signal, the connect
>> attempt is terminated and a new connect() call needs to be done.

>> But, if there is for example a process that needs frequent timer
>> interrupts, and the machine to connect to do not respond until the
>> next timer interrupt has been delivered the process can never
>> connect to it.

Right.  This is a problem with using signals to implement timers: you
have to be prepared to get EINTR from practically everything; I usually
end up doing everything nonblocking.

Sometimes this proves to be a good thing.

Sometimes.

>> Posix specifies that if a connect() call is interrupted, the
>> connection attempt shall not be aborted but instead be established
>> asynchronously.

Then we should do so, it seems to me. :-)  Especially since it is
approximately API-compatible with software that expects an EINTRed
connect() to be trashed, since such programs will generally close the
socket and retry.  The only programs that might be broken by it are
those that assume that EINTR means the socket is still unconnected and
is suitable to try a new connect() on.

However, if POSIX says it, such programs are now broken de-jure and if
not now soon will be de-facto, so I'm not convinced we should care
about them.  (I don't know of any offhand.)

> I'm not quite sure I understand the expected behavior here.

The expected behaviour is that from connect(), EINTR should be treated
as approximately equivalent to EINPROGRESS, or at least that's how I
read it.

> How is the application ever supposed to know that the connect() has
> completed?

The same way it does for a connect() on a nonblocking socket,
presumably.  connect(2)'s description of EINPROGRESS describes how this
can be done.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B