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

Harald Kipp harald.kipp at egnite.de
Mon Nov 30 11:19:13 CET 2009


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

> 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.


More information about the En-Nut-Discussion mailing list