Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ames!elroy.jpl.nasa.gov!sdd.hp.com!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!excelan!george
From: george@na.excelan.com (George Powers)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: select() call weirdness
Message-ID: <2629@excelan.COM>
Date: 21 Jan 91 21:57:16 GMT
References: <9101171257.AA13517@fiamass.ie>
Sender: news@excelan.COM
Reply-To: george@novell.com (George Powers)
Organization: Novell, Inc., San Jose, Califonia
Lines: 41

In article <9101171257.AA13517@fiamass.ie> fiamass@fiamass.ie (fiamass) writes:
>
>We are having a problem with the select() system call on a Sun Sparc 4/65
>running SunOS 4.1.  We have a non blocking socket which we use to issue 
>a connect().  This call returns EINPROGRESS as per the documentation.  The 
>documentation states that under these circumstatances a select() call for 
>write on that socket can be done to determine when the socket is fully
>connected. Now here is our problem, we make a select() call which 
>always seems to return telling me 
>that the socket is now connected. So on I go and issue a write() which
>causes the program to bomb out!  It is as if the write call does not return.
>Here us the code. Has anyone any ideas?

This question deals in an aspect of socket programming that seems
to be frequently misunderstood, so I am posting my response:

I am not sure exactly why your program fails, but your code does
not conform to standard practice in using select.

One problem is that you assume that select completion means that the
socket is in the next expected state.  Owing to the nature of select's
implementation, you must treat it as meaning that the socket might be
in the expected state, but then again it might not be.  It may have
suffered an error, or it may just be a false alarm.  You should retry
the connect operation after each select returns until connect returns
errno==EISCONN.  Then try the write operation.

Also, your select specifies a zero wait time, which means that in this
example the connection is probably not established when you try the
write.  You should probably wait indefinitely.

These remarks pertain to operations besides connect.  When you select
for writing, you should be prepared for write to return EWOULDBLOCK,
or to write only part of the amount requested.  You may not observe
these things in practice, but they can happen on some systems in
certain circumstances, without violating the operations as documented.

--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!novell!george  George Powers
Internet: george@novell.com 
--