[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #19161] lwip_select mishandles sub 500us delays
From: |
Jonathan Larmour |
Subject: |
[lwip-devel] [bug #19161] lwip_select mishandles sub 500us delays |
Date: |
Fri, 23 Mar 2007 06:14:18 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060513 Fedora/1.0.8-1.1.fc3.1.legacy Firefox/1.0.8 |
Follow-up Comment #3, bug #19161 (project lwip):
I see the fix is to tweak it to 1ms, which is fair enough in the current
context. The same thing happens in api_lib.c in two places - a 1ms timeout is
used in order to be interpreted as a poll. I'd be concerned that ports may
unnecessarily wait 1ms though. I know in my port I map 1ms waits to a poll.
Perhaps we should just do the right thing and either:
a) document that a 1ms timeout should always be considered a poll - the
precise timings of lwip operation being somewhat variable as it is; or
b) provide new polled versions in sys.c: sys_mbox_tryfetch, and
sys_sem_trywait, which would just be #defines to sys_arch_mbox_tryfetch and
sys_arch_sem_trywait. (Which ports may in turn choose to make #defines to
sys_mbox_arch_fetch(mbox, 1) to preserve existing behaviour if they wish).
The latter is clearer, but breaks existing ports. Any opinions out there?
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?19161>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [bug #19161] lwip_select mishandles sub 500us delays,
Jonathan Larmour <=