[lwip-devel] [bug #19161] lwip_select mishandles sub 500us delays

[Jonathan Larmour]

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/