[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] Compile errors with lwip 0.7.0 and contrib-20040122
From: |
John Taylor |
Subject: |
RE: [lwip-users] Compile errors with lwip 0.7.0 and contrib-20040122 |
Date: |
Wed, 28 Jan 2004 07:30:24 -0500 |
>>>Another thing that has puzzled me a bit, is that sys_msleep() is now
>>>forced to use the overhead of allocating and deallocating a semaphore
>>>on every call. Wouldn't it be better to allow sys_msleep() to be
>>>implemented in sys_arch.c?
>>>
>>>
>>
>>I remember looking at that long ago and I am not sure why but did not
>>change anything. Maybe the fact that it uses lwip semaphores allows
lwip
>>timers to fire whereas a native sleep would not trigger the timers of
>>the sleeping thread.You could check and see if that's the case, I'll
do
>>it with the ecos port sometime soon.
>>
>>
>IIRC that's not the case. So far sys_msleep() is only used for PPP,
>where native sleep had been working OK.
No, the sys_msleep() call is required for the lwip timers to fire
properly. Using a native sleep will delay the firing of all 'active'
timers at the time the sleep call is made. Now, if there are no
'active' timers when the thread is sleeping - no harm, no foul. Or if
the amount of time spent sleeping is relatively small compared to the
timer period, it is probably not noticeable. However, as good practice,
I recommend *not* replacing the sys_msleep() with a native sleep call.
FYI: This is fresh on my mind, because I too thought the implementation
of sys_msleep() was "klunky" until I completely understood how lwip
timers work - then it make perfect sense.
-john
_______________________________________________
lwip-users mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Compile errors with lwip 0.7.0 and contrib-20040122, christiaan . simons, 2004/01/28