Subject: Re: connect() problems.
To: None <email@example.com>
From: Charles M. Hannum <firstname.lastname@example.org>
Date: 05/16/2004 13:59:57
On Saturday 15 May 2004 09:34, email@example.com wrote:
> 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.
> Posix specifies that if a connect() call is interrupted, the connection
> attempt shall not be aborted but instead be established asynchronously.
> The patch below is what solves the problem and also makes connect()
> more posix conformant. It is the same solution that solved the
> problem in FreeBSD. Comments?
I'm not quite sure I understand the expected behavior here.
How is the application ever supposed to know that the connect() has completed?
Doing a second call to connect(2) will currently cause it to disconnect and
reconnect (if the connect has completed) or return EALREADY (if the connect
has not yet completed). This doesn't seem like useful behavior.