The problem is that the second connect() call is failing with an EALREADYCONNECTED. The correct way to detect an error from connect, according to Single Unix, is to do a poll or select. If select/poll return with an error or they timeout, the connect failed. If they return successfully, then the connect has succeeded.
Ryan On Monday 06 August 2001 14:22, Jeff Trawick wrote: > [EMAIL PROTECTED] writes: > > There shouldn't be a reason to call connect again in the chunk > > below since apr_wait_io_or_timeout should return success if we can > > use the socket or error if we've timeout. > > The purpose of the connect call is to find out whether or we have a > connection. It is much better to find an error (e.g., ECONNREFUSED) > here than have a subsequent read or write fail. Applications don't > tend to have as friendly an error path when send or recv fail as they > do when connect fails since a connect failure is normal behavior (user > specified bad input). -- _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
