Closing a socket.
chrisj at rtems.org
Fri May 13 14:07:04 UTC 2005
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
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.
More information about the users