[En-Nut-Discussion] killing threads waiting for a connection in NutTcpAccept

[José Vallet]

Thanks Tim and Henrik.

I was thinking about timeouts as a possible solution, but I was trying 
to avoid changing the OS sources, specially not being sure about what I 
was doing and where exactly to punt my hands on.

In any case a time out is not exactly what I need. In my application the 
server thread blocked by NutTcpAccept will receive connections very 
seldom, and so the thread will be executed rarely. This is desirable as 
other more important threads can be running in an already quite loaded 
system.

I'd like to be able to kill the thread quickly as other threads will be 
waiting for this to happen. Using small timeouts would make the thread 
to execute periodically when waiting for connections loading the system 
still a bit more, which I am trying to avoid.

Sending an event to sock->so_pc_tq indeed produces a quick reaction, and 
it seems to work, at least within a short term (couple of trials). My 
fear is that, due to my ignorance about the stack internals, I could be 
doing something that could brake the stack, perhaps in the longer term, 
and halt the system or something similar. Still to my poor understanding 
it seems logical to think that, as long as the code between NutTcpAccept 
and NutTcpCloseSocket does NOT do any read or write operation on the 
socket, nothing horrible should happen. Any hits, confirmation or 
clarifications/comments about this are very welcomed.

In any case, if I find problems I will go for the timeouts and will have 
to live with patches.

Thanks!
José

Henrik Maier wrote:
> Hi Jose,
> 
> This problem is not new and has been discussed (but not resolved) before.
> Refer to discussion thread "NutTcpAccept() timeout" dated 7/2006 and
> "NutTcpAccept() time-out proposal" from 3/2006.
> 
> I ended up adding a patch to my private Nut/OS build which implements a
> time-out. In NutTcpStatePassiveOpenEvent change:
> 
>      NutEventWait(&sock->so_pc_tq, 0);
>      return 0;
> 
> to:
>      return NutEventWait(&sock->so_pc_tq, sock->so_read_to);
> 
> This makes the read time-out also apply to accept.
> 
> Henrik
> 
>> -----Original Message-----
>> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
>> bounces at egnite.de] On Behalf Of José Vallet
>> Sent: Tuesday, 7 April 2009 1:52 AM
>> To: Ethernut mail list
>> Subject: [En-Nut-Discussion] killing threads waiting for a connection
>> in NutTcpAccept
>>
>> I have some threads waiting for connections with NutTcpAccept, and I'd
>> like to kill them.
>>
>> The (simplified) code goes like this
>> __________________
>> ...
>> sock = NutTcpCreateSocket();
>> NutTcpAccept(sock, SERVER_PORT);
>> mystream =_fdopen((int) sock, "r+b");
>> whihle(!disconnect)
>> {
>> ...
>> }
>> fclose(sl_stream);
>> NutTcpCloseSocket(_sl_sock);
>> NutThreadExit();
>> __________________
>>
>>
>> The problem is that while the connection does not arrive the thread is
>> blocked waiting for connections, and thus the thread will never reach
>> NutThreadExit.
>>
>> I have "solved" this by sending from another thread an event to
>> "sock->so_pc_tq", which is the queue where NutTcpStatePassiveOpenEvent
>> (called from NutTcpAccept) blocks waiting for events (connections). The
>> result is that, as the stack thinks that a valid connection has
>> arrived,
>> all the code between NutTcpAccept and NutThreadExit() is executed
>> normally as if the connection had arrived properly.
>>
>> Though I can live with this for my particular application, I guess this
>> solution is ugly and dirty (at least to me) and I wonder if there is
>> any
>> other better solution to unblock the thread waiting for connections
>> (note: closing the socket does not unblock NutTcpAccept).
>>
>> Thanks and regards
>> José
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>