[En-Nut-Discussion] rs232d: closing socket while other thread is write blocked on socket

[Harald Kipp]

Mmmm...

I checked the sources and can't find a potential problem.

Henrik Maier wrote:
> It came to my attention that the rs232d.c demo actually closes the socket
> while the other thread could still be write blocked on it. In that scenario
> the socket is destroyed while being used.

This is intentionally built in. It is explicitly allowed to call
NutTcpCloseSocket(sock) in one thread, while the socket is in use by
other threads.

Note, that a TCP socket is not immediately destroyed when calling
NutTcpCloseSocket(). It simply changes its state from TCPS_ESTABLISHED
to TCPS_FIN_WAIT_1.


> For example Receiver() is blocked in the fwrite() call while main()  returns
> from StreamCopy() due to connection break down and calls fclose(). 

As soon as the socket changes from TCPS_ESTABLISHED to something else,
all waiting threads are removed from the transmit queue (so_tx_tq).

I expected a problem with the higher level stream, but can't find any.


> Shouldn't in such a use case fwrite and fclose be synchronised by mutexes?

Is this a hypothetical assumption or practical experience? So far I
didn't run any test, I just reviewed the code.

Harald