[Top][All Lists]

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

[lwip-devel] [bug #19167] tcp timeout handler can cause crash being invo

From: Andreas Becker
Subject: [lwip-devel] [bug #19167] tcp timeout handler can cause crash being invoked by sys_sem_wait()
Date: Wed, 28 Feb 2007 10:35:14 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.4 (like Gecko) (Debian)

Follow-up Comment #2, bug #19167 (project lwip):

Hi all,

I know this Problem. Let me suggest an more ... "complete" solution...
Lwip uses this semaphore and queue functions to get something like a
"timefeeling". The "timefeeling" is an soft timeout, that tells you something
like "The time is over", not the real correct value. The consequence of this
is, that (under heavy load) the timer will fire later than we expect -> e.g.
500ms to 520ms but that's not a real problem.

suggestion: remove ALL timeouts from semaphores, only use queues for
timeouts. Than the invoked timer will only called, if an thread is in a
suitable situation for executing Timers. This gives us new style semaphores,
which only know blocking operations.
new problem: we will loose much more of our time-correctness. the
"timefeeling" would be much worser than now. A lot of time will be taken by
the run-time of a thread, which sometimes has to (blocking-) wait for other
semaphores (new style). 
MY solution is to remember the time(-stamp) where we continue a thread from a
queue (message or timeout). On the next time, where we wait for a new message,
we have to decrement the timeout-timer with the difference of the actual
time(-stamp) and the remembered time(-stamp). Posible execute some timeouts
and then wait for the next timeout or queue-message.
A other advantage of this is, that the sys_sem_wait functions will run much
faster, because there is much lesser code to execute.



Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

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