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

[Harald Kipp]

Henrik Maier wrote:

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

I remember having used this technique more than once, killing a
connection in one thread by closing the socket in another thread.

Nevertheless, it will be worth to check this in detail once again. The
state machine had been changed a number of times in the meantime.


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

That's right. NutTcpStateChange should be called by the state machine to
change the state and properly setup any socket transmission flags.

NutTcpStateProcess is a multiplexer, passing the incoming packet to the
right processing routine, based on the current socket state.

I'm also a little bit confused by the handling of NutTcpStateCloseEvent,
because I expected something like

  NutEventBroadcast(&sock->so_rx_tq);
  NutEventBroadcast(&sock->so_tx_tq);
  NutEventBroadcast(&sock->so_pc_tq);
  NutEventBroadcast(&sock->so_ac_tq);

in this routine. In fact the change to TCPS_FIN_WAIT_1 will send out a
FIN. If this is acknowledged by a new incoming segment, the stack
already left TCPS_ESTABLISHED and

  NutEventBroadcast(&sock->so_tx_tq);

will _not_ be called in NutTcpStateProcess anymore.

So far it looks to me, that it is possible to have a transmitting thread
left alone in the dark. In reality this will probably happen in very
rare cases, but now I see the point. Further investigation is required.

Harald