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

[Thiago A. Corrêa]

Hi José,

   Looks like there is no easy solution, and both sounds a bit ugly to me.

   I think it would be acceptable to have an NutTcpAccept timeout as
long as it's not tied to the receive timeout and made configurable so
the extra code doesn't need to be included for those not willing to
use it.

  Perhaps we should try to address why would you want to kill the
thread in the first place. I can't think of any reason.

 Just my 2 cents.

Kind Regards,
   Thiago A. Correa


On Tue, Apr 7, 2009 at 2:26 AM, José Vallet <jose.vallet at hut.fi> wrote:
> 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
>>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>