Subject: Re: ALERT: Solaris 2.5.1 locks up on TCP connections in Pine 3.9x

From: Mark Crispin <[email-masked]>
Date: Tue, 26 Nov 1996 10:14:54 -0800

On 26 Nov 1996, Casper H.S. Dik wrote:
> Mark Crispin <[email-masked]> writes:
> >2) The 0 byte read serves a purpose.  On all systems except Solaris, it
> >   enables Pine to report a TCP/IP connection failure after doing a
> >   blocking select().  Otherwise, a failure to open the connection will
> >   not be detected until Pine tries to read data from the connection, and
> >   it will report the wrong message.
> It still is bad programming; the proper way to do a non-blocking connect is
> to retry the connect you eitehr get an already connected error or
> a timeout.

Please explain why an extraneous connect() is in any way "better"
programming than an extraneous read().  "Not the way I do it" does not
equate to "bad programming".

The extraneous read() allows determination of "success" vs. "failure" by
whether or not the read() fails.  A successful (= no-op) read() means
success.

The extraneous connect() requires the programmer to analyze the returned
error code to determine "success" vs. "failure" condition.  That, in turn,
can lead to portability problems.

Is SUN willing to guarantee that all ports of UNIX and all UNIX-like
systems for all time will only return a certain connect() error code (or
codes) in the success case, and will never return any of those code in the
failure case?  Somehow, I doubt it.

In any case, a different technique is used in Pine 4.00.

-- Mark --	Read http://www.imap.org for the "best kept secret in email"

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.