Closing a socket.

Chris Johns chrisj at
Fri May 13 14:07:04 UTC 2005

Joel Sherrill <joel at> wrote:
> Yes it does appear that there are multiple points where blocking
> can occur but don't they all boil down to only a handful of calls
> to event_receive?

Yes it does.

> There are only 3 calls to soconnsleep()in addition to the accept()
> routine. They would just have to be fixed.
> Also there are only a handful of event receive calls in the stack
> as well.
> This shouldn't be a hard thing to do.  One approach is to send a
> deleted event and let the code after the receive check for that
> event.

The event is easy, knowing when to use it is not. The API from the 
networking code provides no way of doing this.

> simply avoid touching the socket memory, and return a
> "deleted" status.  Those calling a blocking helper would have
> to put the return status into a local variable and make sure it
> was OK to reference malloc'ed memory.

I do not wish to touch the BSD code and this is what would be needed. 
This means the close thread that does a wake needs to block.

> If you don't use the deleted event, then you should be able to return
> status through the TCB and just use that.  Again if the socket is 
> deleted, then code has to avoid touching malloc'ed memory.

I have a solution which I have tested accept and recv calls with and 
they work well. The other paths are much harder to generate tests for so 
I have done a code audit and it looks ok. I have tested this with 
OpenSSL and TSL connections and do not see any problems.

The fix uses a CONNABORT event to wake the sleeper and a socket state 
flag to cause the abort event to be used. The close sets the SS_ASYNC 
flag in the socket so the wake calls know to send the abort event. I 
checked the code and SS_ASYNC is not used anywhere. The error code 
returned is ECONNABORT.

The soconnsleep and sbwait work the same way when recovering from a close.

The twist to using the abort event is the wake caller (close thread) has 
to blocked until the woken thread is clear of the networking code.

  Chris Johns

More information about the users mailing list