re: interrupting connect(), EINTR, EINPROGRESS, EALREADY, and so on

re: interrupting connect(), EINTR, EINPROGRESS, EALREADY, and so on

[Dan Kegel]

David Madore wrote:
 > http://www.eleves.ens.fr:8080/home/madore/computers/connect-intr.html
Interesting.

I'd suggest bringing this up on the austin-group-l list,
see http://www.opengroup.org/austin/lists.html
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

re: interrupting connect(), EINTR, EINPROGRESS, EALREADY, and so on

[Alan Cox]

On Gwe, 2003-04-25 at 06:40, Dan Kegel wrote:
> David Madore wrote:
>  > http://www.eleves.ens.fr:8080/home/madore/computers/connect-intr.html
> Interesting.
> 
> I'd suggest bringing this up on the austin-group-l list,
> see http://www.opengroup.org/austin/lists.html

Linux is perhaps a little friendlier but it isnt clear. The socket api
drafts have an even more fun bug. For some protocols "bind" is a
blocking operation but the API was written by someone who never
considered this

interrupting connect(), EINTR, EINPROGRESS, EALREADY, and so on

[David Madore]

Hi.

I hope this is not too off-topic for this list.  I have discovered
discrepancies between various Unix implementations and/or their
documentation, and the Single Unix Specification, concerning the
behavior of the connect() system call for blocking, stream, sockets,
when it is interrupted by a signal.  Rather than explain it all, I'll
refer you to the Web page I just wrote about this, namely <URL:
http://www.eleves.ens.fr:8080/home/madore/computers/connect-intr.html
>.

I believe that the behavior Linux uses is the best, but it seems to be
at odds with a literal reading of the Specification.  (Details and
explanations are on the page I've just mentioned.)  I'd like to know a
little more about this, e.g., how it was decided and by whom, and
when, and what arguments can be given to support it.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.eleves.ens.fr:8080/home/madore/ )