Opened 3 years ago

Closed 3 years ago

#13662 closed bug (fixed)

Subsequent connect() call shouldn't return EINPROGRESS (before the connection is established)

Reported by: korli Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: Network & Internet/TCP Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


If the connection cannot be established immediately and O_NONBLOCK is set for the file descriptor for the socket, connect() shall fail and set errno to [EINPROGRESS], but the connection request shall not be aborted, and the connection shall be established asynchronously. Subsequent calls to connect() for the same socket, before the connection is established, shall fail and set errno to [EALREADY].

See issue 1568 at Haikuports for an example.

The error code seems to originate from

	// Can only call connect() from CLOSED or LISTEN states
	// otherwise endpoint is considered already connected
	if (fState == LISTEN) {
		// this socket is about to connect; remove pending connections in the backlog
		gSocketModule->set_max_backlog(socket, 0);
	} else if (fState == ESTABLISHED) {
		return EISCONN;
	} else if (fState != CLOSED)

IMO the EINPROGRESS should be replaced with EALREADY.

Change History (3)

comment:1 by phoudoin, 3 years ago

Agreed, as the initial EINPROGRESS response is actually handled a bit bellow instead of blocking while waiting for handshake.

Last edited 3 years ago by phoudoin (previous) (diff)

comment:2 by korli, 3 years ago

Possible fix applied in hrev51358. Tested OK so far.

comment:3 by korli, 3 years ago

Resolution: fixed
Status: newclosed

No feedback from original reporter at HaikuPorts. Closing as fixed.

Note: See TracTickets for help on using tickets.