[lwip-users] Re: [lwip] sys_timeout()

[Adam Dunkels]

Hi!

On Thursday 18 October 2001 14:44, you wrote:
> As you said earlier, a timeout handler is never called, as long as the
> thread asking for the timeout has not blocked. So somehow the timeout
> management must know if the *right* thread is blocking for a sema/message.
> I do not (yet) understand how timeout management can know that without
>
> knowing sema/message status
>
> or
>
> knowing thread status information.

The time-out management isn't that hard, really. I think I have messed up my 
explanation of it, so I'll start all over, from the beginning :-)

Assume that we have a system with one thread only (this applies to 
multithreaded systems as well; each thread will behave like this). This 
thread runs the lwIP TCP/IP code, which basically does the following:

while(1) {
   sys_mbox_fetch(packet);
   process_incoming_packet(packet);
}

Now, in the sys_mbox_fetch() function, the following pseudo code illustrates 
what happens:

sys_mbox_fetch() {
start:
   if(there_are_scheduled_timeouts) {
      time_until_next_timeout = calculate_time_until_next_timeout();
      if(mfetch_t(mailbox, time_until_next_timeout) == TIMEOUT) {
          call_timeout_handler_for_this_timeout();
          goto start;
      } else {
         return;
      }
   } else {
      mfetch(mailbox);
   }
}

The functions mfetch() and mfetch_t() are made up names of functions of the 
underlying OS. The mfetch() function blocks the thread indefinately and 
fetches a message from a message queue, and mfetch_t() does the same but 
blocks the thread for a specified amount of time.

So, in effect, time-out handlers will never be called when a thread isn't 
waiting for a mailbox or for a semaphore. Of course, from the underlying OS' 
point of view, the thread will be running when it is executing a time-out.

Hope this explains a bit better. :-)

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]