Re: [lwip-users] sys_arch.c timeout of zero problem

[address@hidden]

lwIP should not have any problems with a timeout of zero. However, 
converting timeout valus inside the function sys_arch_mbox_fetch() (like 
you did) is not supported and will confuse the stack. This is because of 
the way the stack handles timers: it keeps the time until the next timer 
expires (in miliseconds) and substracts the time sys_arch_mbox_fetch() 
needed from that time. When zero, the timeout gets called.

There are two possibilities here:
a) the function returns a valid mbox message, in this case it shall 
return the time (in miliseconds) it needed until the message was 
received, zero if received immediately or
b) the function returns SYS_ARCH_TIMEOUT if timeout is !=0 and no 
message has been received in that time; in this case the time needed is 
supposed to be the value of timeout passed to the function.

Now you can easily see that returning SYS_ARCH_TIMEOUT after 0 
miliseconds instead of 10 miliseconds will lead to problems as the stack 
thinks 10 ms have passed but in reality, 0 ms have passed. Because of 
that, timers get called much too frequently and this may lead to 
detecting connection errors where there aren't any.

If you are using lwIP 1.3.0 or newer (CVS), to achieve what you want, 
have a look into the netconn_recv() function: when you have 
LWIP_SO_RCVTIMEO defined to 1, sys_arch_mbox_fetch() gets called with a 
timeout defined in the netconn (conn->recv_timeout), an int which you 
can set to whatever you want, e.g. set it to -1 and let 
sys_arch_mbox_fetch() return immediately if timeout is -1.

If you are using lwIP 1.2.0 or before, I don't know a decent solution.

BTW: The above timeout implementation is not ideal and subject to change 
in lwIP 1.4.0. With the intended solution (having a function like 
get_time()), your approach would have worked ;-)

Simon


David Shmelzer wrote:
> My application requires that netconn_recv() be non-blocking and to
> return immediately of there is no message waiting.
> So I modified sys_arch.c to convert small timeout values to zero for the
> queue wait. 
> But I run into problems if the xQueueReceive timeout is 0. The TCP
> connection closes after ~5 netconn_recv calls. Everything works fine if
> the xQueueReceive blocks for at least 1 tick.
> Does the lwIP architecture REQUIRE that netconn_recv allow the lwIP
> thread to run? 
> Is there a reason that it was designed such that a timeout of 0 means
> wait forever instead of peek? 
>
>
> Here's my modification to sys_arch.c:
>
> u32_t sys_arch_mbox_fetch(sys_mbox_t mbox, void **msg, u32_t timeout)
> {
> ...
>         if ( timeout != 0 )
>         {
>             timeout >>= 2; <<<<<---- added this line which converts
> timeout in ms to ticks
>                 if ( pdTRUE == xQueueReceive( mbox, &(*msg), timeout ) )
> ...
>
>
>
> Thanks
> -Dave
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>