[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: address@hidden
Subject: Re: [lwip-users] sys_arch.c timeout of zero problem
Date: Tue, 11 Aug 2009 19:29:39 +0200
User-agent: Thunderbird (Macintosh/20090605)

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 ;-)


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 ) )


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]