Closing a socket.

[Chris Johns]

Joel Sherrill <joel at OARcorp.com> wrote:
> 
> But if the socket is closed, then shouldn't there be a path from the
> blocking object going away which indicates an error occurred so
> future references to freed resources can be avoided.
> 

I have been looking into the code and making progress but see a 
potential problem I would like feedback on.

Some of system calls in rtems_syscalls.c need to pass parameters to the 
BSD code in an mbuf. This is a source of socket close problems as the 
mbuf request is WAIT. If the mbufs are gone the network semaphore is 
released a close could proceed and free the socket struct which the 
system call has a pointer to and using.

This is simple to fix by reordering the system calls to get the mbuf 
before the socket struct is obtained from the fd. If the socket closes 
while waiting the socket struct will not be found and call will fail 
with an error.

The problem how-ever is the lack of mbufs could hold the system call for 
an unknown period of time and a close would not have any effect. If a 
thread is to delete itself which is what we seem to agree on, the thread 
will also be blocked.

Should the m_get call be changed to no wait and ENOBUFS returned in errno ?

-- 
  Chris Johns