RE: [lwip-users] Compile errors with lwip 0.7.0 and contrib-20040122

[Peter Graf]

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