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

[Henrik Maier]

Harald,

Please disregard my previous post I had not seen yours. 

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

I think it is worthwhile to clarify the concurrent use of sockets in
different threads.

I initially followed the rs232d pattern but became suspicious if that is
safe to do. Hence I checked the code and also posted the naive question in
the mailing list if one better uses a mutex here.

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

Good, and it is very convenient if it works that way.
 
> 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.

Is it always guaranteed that the thread waiting on so_tx_tq is woken up
BEFORE NutTcpDestroySocket is called? What about the case the thread calling
NutTcpCloseSocket has higher priority and continues execution?

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

Just an assumption yet, based on call tree review (Nut/OS 4.4.1). But I am
not an expert on the TCPSM, so I did not catch the so_tx_tq queue removal.
Only saw so_rx_tq, so_pc_tq and so_ac_tq.

Btw, doesn't NutTcpStateChange change the state straight away in that case
without going through NutTcpStateProcess?

Henrik