Closing a socket.

[Chris Johns]

Joel Sherrill <joel at OARcorp.com> 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