[En-Nut-Discussion] killing threads waiting for a connection in NutTcpAccept
Henrik Maier
hmnews at proconx.com
Tue Apr 7 01:47:04 CEST 2009
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
More information about the En-Nut-Discussion
mailing list