Re: [lwip-users] lwip tcp hangup

[FreeRTOS Info]

I'm trying to follow this discussion, but it is not clear to me why the
delay is required at all?

Presumably accept() will keep the task in the Blocked state (i.e. not
using any CPU time) until there is something to accept.  This is the
intended usage model when using any kernel, be it FreeRTOS or otherwise,
isn't it?

When there is something to accept, a task is created to handle the
connection (if necessary, but that could become unwieldy if there are a
*lot* of simultaneous connections), then the original task loops back
and Blocks again until there is something else to do.

Am I missing the point here - and if so - what is the point I am missing?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 01/09/2011 10:23, Simon Goldschmidt wrote:
> vincent cui <address@hidden> wrote:
>> while (1) 
>>      {
>>         clientfd = lwip_accept(lSocket, (struct sockaddr*)&client_addr,
>> &addrlen);
>>              if (clientfd > 0)
>>              {
>>                      xTaskCreate( httphandler, NULL, 128, (void *)&clientfd,
>> HTTP_TASK_PRIORITY, NULL );
>>                      vTaskDelay(100);
>>              }
>>              else
>>              {
>>                      lwip_close (clientfd);
>>              }
>>     }
>>
>>
>> I have added it after accept loop.... 
> 
> No, after the accept() call, but before the next accept() call in the loop, 
> so between 2 calls to accept(), you will delay.
> 
> Simon