lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes are tooti


From: Goldschmidt Simon
Subject: RE: [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes are tootightly integrated
Date: Fri, 9 Mar 2007 10:41:05 +0100

> 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).

If you measure using lwip sys_timeout(), aren't the meassured results
inaccurate?

> 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.

That's true...

> 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 

OK, but what does it help if an application timeout is triggered while
in an api_lib.c function? You can't do anything about the function call
anyway, it will go on waiting after the timeout callback has been
called. AND you must not call lwip functions in that state or you will
REALLY have to know what you're doing (and that's what I call hacking,
not programming...)

I think if you need timeouts in applications using multithreading lwip,
you have to do it using OS functions directly, not lwip sys-functions.
This way, we could guarantee lwip function calls are consistent.

> 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.

That we have already taken care of by initializing those timers in
tcpip_thread().



Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]