Closing a socket.

[Joel Sherrill <joel@OARcorp.com>]

Chris Johns wrote:
> Till Straumann wrote:
> 
>>
>> I agree. It's not OK to close a socket another thread is blocked on.
> 
> 
> I think having a close unblock the thread and return an error code is 
> the best solution.
> 
>> Besides so->so_pgid, the surrounding/calling syscall (accept, ...)
>> also accesses the already released socket struct.
> 
> 
> Yes. I am looking at this.
> 
>>
>> OTOH, deleting a blocked thread doesn't seem like a good solution either
>>
> 
> This is a definite no no. Unless the networking lock is move to the TCB 
> and support added (which would be complex), it is not a good idea to 
> delete a thread making networking calls.

This is the crux of the solution.  The returned error status must get 
back to the blocked thread only using memory that has a lifespan longer 
tied to the thread.  The TCB has a return status code but it is probably
used back to the point at which the blocking call.

Since it is blocked on an event, the object it is waiting on is not
going to disappear with the deletion of the socket.  Thus it doesn't
get a hint there.

My next thought would be that you would have to receive a "socket
deleted" event.  This would require adding an event to the set
used.  If you wake up because of the "deleted" event, the task
is obligated to return an error without touching the pointer.
The rtems_glue.c soconnsleep() and accept() code would have to
honor this.

> The rule I use is any thread that makes networking calls deletes itself.
> 
>> --> I believe the rtems syscalls should be changed to make it safe to
>> close a socket on which another thread is blocking. This could be 
>> achieved
>> e.g., by letting soconnsleep/soconnwakeup use different events if the
>> socket is being closed and propagating  an error code that prevents
>> the socket structure being from accessed from the RTEMS glue code
>> in this case.

Hmmm .. thinking before reading. :)  Sounds like a good solution. :)

> ... or block the close until the blocked thread has returned. I have 
> something which appears to be working for accept, and I am now looking 
> at the other calls.

This would work but could be more complicated to get right.

> Using another event, say SOCLOSED is a good idea. I may look at this. 
> Thanks for the idea.

A working fix that is not TOO broad would be OK for 4.6.x.


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985