In message <20030819134900.GA27340845@qnx.com>
	on Tue, 19 Aug 2003 09:49:00 -0400,
	Sean Boudreau <seanb@qnx.com> wrote:
> This ties in with the observation I raised in tech-net
> on June 17 WRT not being able to call connect() again after
> ECONREFUSED.  It didn't generate much debate at the time.
It isn't the same situtation.  I don't want to connect() another
destination socket address after ECONREFUSED error at all.

My point is:

o the case of using non-blocking I/O.
o repeating connect() to the same destination for checking it
  completed or not after EINPROGRESS error.

When using non-blocking I/O, connect() is expected to behave as:

1. first connect() results error with EINPROGRESS.
2. following connect() results error with:

	EALREADY	still operation is in progress
	EISCONN		connection is established (connect success)
	really error	ECONNREFUSED or other error

   But currently EINVAL may happen, not described in connect(2).

Other interpertation, connect() is expected to behave as:

1. first connect() results error with EINPROGRESS.
2. following connect() results error with:

	EALREADY	still operation is in progress
	EISCONN		connection is established (connect success)
	EINVAL		real error status should be fetch with
			getsockopt(2) (SOL_SOKCET/SO_ERROR).

   Thus current connect(2)'s documentation is wrong?

-- 
Takahiro Kambe <taca@back-street.net>