[En-Nut-Discussion] NutTcpAccept blocks the tread

[Henrik Maier]

Hi Harald,

I think this is exactly what I was after with my earlier proposal in 2006. 

Henrik

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Friday, 23 October 2009 7:05 PM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] NutTcpAccept blocks the tread
> 
> Hi Nathan,
> 
> Nathan Moore wrote:
> > My second idea was to have the wakeup of "this thread" happen before
> > changing the state of the socket to closed.
> > Then when "this thread" is run code within NutTcpAccept
> > (NutTcpPassiveOpenEvent, actually) will:
> >   1. examine the state of the socket and decide if this is strictly a
> > timeout.
> >      (note:  if the timeout happens at the same time as an incoming SYN
> this
> > would give preference to the SYN)
> >   2. If it is strictly timeout it would asyncronously change the
> socket's
> > state to closed and return a value to let the
> >       caller know that a timeout has happened.
> > This way if "this thread" doesn't sleep before it calls NutTcpAccept
> again
> > there can be no moment where a network
> > interface's RX thread is running while the socket is not listening.
> 
> Considered, that NutTcpPassiveOpenEvent had been changed following your
> suggestion, the application will use the following pseudo code:
> 
> for (;;) {
>   CreateSocket();
>   SocketOption(Set read timeout);
>   while (NutTcpAccept()) {
>     /* Timout, do something else,
>     ** but do not sleep. */
>   }
>   /* Handle the connection. */
>   ...
>   /* Finally */
>   DestroySocket();
> }
> 
> Is that what you meant?
> 
> Harald
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion