|
From: | Peter Graf |
Subject: | RE: [lwip-users] Compile errors with lwip 0.7.0 and contrib-20040122 |
Date: | Thu, 29 Jan 2004 00:04:35 +0100 |
John Taylor wrote:
>>No, the sys_msleep() call is required for the lwip timers to fire >>properly. >> >sys_msleep() is not required for the lwIP timers at all. Just do a >find/grep on the code and you'll see that it is nowhere called except >from PPP. I have lwIP running nicely with sys_msleep() compeletely >removed. You are correct, that the lwIP timer mechanism is not dependent on the sys_msleep() call/implementation. The lwIP timer mechanism works by 'taking over' the waiting whenever the application calls sys_mbox_fetch(), sys_sema_wait_timeout(), and sys_sema_wait(). Instead of just blocking until signaled, these call actually block-with-a-timeout where the timeout period is the period of the next registered timer to expire (Note: sys_wait_timeout() is implemented by first registering a timer for the user specified timeout period and then waiting to be signal). If lwIP registers a timer, via sys_timeout(), and then never calls sys_sema_wait(), sys_sema_wait_timeout(), or sys_mbox_fetch() such that these calls block, none of the registered timers ever expire.
Apart from the fact that there is no sys_wait_timeout(), this is about correct, but IMHO unrelated to our issue.
Now back to sys_msleep(). Currently sys_msleep() is implemented by calling sys_sema_wait_timeout(). This is done so that while the thread is sleeping/waiting, any registered timers will *still* expire correctly. Bypassing the sys_sema_wait_timeout() implementation will have a *negative* effect on all currently registered timers of the thread that calls sys_msleep().
I can not see what the nature of this negative effect should be. If there was a negative effect, there would also be one when this thread is running or blocking for I/O, because sys_sema_wait_timeout() and it's implications aren't called from _this_ thread then, either.
If I find the time, I will have a critical look at sys_sem_wait_timeout() also. It is not part of the system structure defined by Adam. Except for the new sys_msleep(), where I dispute it's necessity, it is called only from a singular point within sockets.c.
My impression is that there is a lack of specification what exactly sys_msleep() and sys_sem_wait_timeout() mean. They have not been part of the original system definitions from Adam, and somehow creeped in. The comment says about sys_sem_wait_timeout():
/* Wait for a semaphore with timeout (specified in ms) */ /* timeout = 0: wait forever */ /* Returns 0 on timeout. 1 otherwise */That comment doesn't explain it's right to live. Classic sys_arch_sem_wait() would be enough.
As I said before having a native implementation of sys_msleep() is 'OK' under certain circumstances. As you pointed out, sys_msleep() is *currently* only used in the PPP code. And I am guessing that its usage is such that there are no registered timer(s) when it is called. The problem with using a alternate implementation for sys_msleep() arises with future releases of lwIP. New releases, new applications, etc. may use sys_msleep() more extensive than it is currently being used. In which case, you will see the negative impact on timers.
I don't see it :-) But before I want even more usage of a new system function that calls another new system funtion, I certainly would like an exact definition of both.
All the best Peter
[Prev in Thread] | Current Thread | [Next in Thread] |