[lwip-devel] [bug #19167] tcp timeout handler can cause crash being invoked by sys_sem_wait()

[Andreas Becker]

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:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/