[lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes are too tightly integrated

[Frédéric Bernon]

Follow-up Comment #3, bug #1902 (project lwip):

Hi, agree with you.

More informations, based on "problems" I cause to Dmity and others with
SO_RCVTIMEO (sorry :( ):

I do lot of tests and measures to evaluate Dimtry's solution
(sys_mbox_fetch_timeout based based on sys_mbox_fetch+sys_timeout, like
sys_sem_wait_timeout is based on sys_sem_wait+sys_timeout), and in fact,
there is not sensible performance difference between his solution and mine (I
try on recv and/or write scenarios, with 4Mbps, and with a sys_timeout(10ms)
in application to check all the code).

But, you can increase performance when you replace in api_lib.c all
sys_mbox_fetch per directly sys_arch_mbox_fetch !! And the code is simpler.
In my case, it's work fine and faster (note, I don't have test "select()"),
but, if like Dmitry, you have to use internal sys_timeout features in your
application level, it's a real problem. But, it's is really good to use lwip
internals features? Perhaps it will prevent to do some futur improvements
inside lwip core? I don't know. We can talk about that...

I also think that current timeouts implementation in sys.c - even if they
help to reduce footprint - are not really efficent (if any internal process
take too "long" time, timer would not be accurate), and some timers (arp,
dhcp, etc...) would have to be used only in tcpip_thread (the real core stack
context when you are in multithread) to be safe-thread.

Perhaps, to kwow what can be done, it will be useful to do a little poll to
learn how most of lwip users integrate it (to know what api can be change to
avoid extra code, what give more performance for most of users, etc....)



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?1902>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/