Invoking setsockopt(,IPPROTO_TCP, TCP_NODELAY,,) on OSX while the socket is still connecting sometimes results in an error with errno set to EINVAL. The man page indicate this is because "the socket has been shut down," but it seems to occur during the connection phase as well.
See discussion in #1381. In tests, I've privately modified the code to query the value of TCP_NODELAY after the connection is completed and it has always reported being set even when the error condition is triggered. It remains possible that this is not always true.
If we wanted to remove the possibility of triggering this error, one solution would be to add a flag to the Network::ConnectionImpl constructor that indicates TCP_NODELAY is desired. Then when the connection is complete (see ConnectionImpl::onWriteReady) we would invoke setsockopt or not based on the flag. The ConnectionImpl::noDelay method would no longer be used publicly.
Invoking
setsockopt(,IPPROTO_TCP, TCP_NODELAY,,)on OSX while the socket is still connecting sometimes results in an error witherrnoset toEINVAL. The man page indicate this is because "the socket has been shut down," but it seems to occur during the connection phase as well.See discussion in #1381. In tests, I've privately modified the code to query the value of TCP_NODELAY after the connection is completed and it has always reported being set even when the error condition is triggered. It remains possible that this is not always true.
If we wanted to remove the possibility of triggering this error, one solution would be to add a flag to the
Network::ConnectionImplconstructor that indicates TCP_NODELAY is desired. Then when the connection is complete (seeConnectionImpl::onWriteReady) we would invokesetsockoptor not based on the flag. TheConnectionImpl::noDelaymethod would no longer be used publicly.