[En-Nut-Discussion] RFC - Nut/OS timer handling

[Harald Kipp]

Hi all,

Some time ago it had been suggested (by Nathan if I remember correctly)
to implement a single utility thread to handle TCP retries, ARP aging
and DHCP updates.

After evaluating this idea in more detail, the idea is to replace these
threads by Nut/OS one-shot timer callbacks.

One problem with this approach is, that timer callbacks are not running
in the same thread context that created the timer. Timer processing is
done in NutTimerProcessElapsed(), which is called in NutThreadResume()
immediately before the context switch takes place.

Btw. a weird side effect is, that runningThread may not be on top of the
runQueue when processing timer callbacks.

The main problem I see is, that more complex routines like TCP
transmission retries may use large amounts of stack space. Because
thread context is undetermined, this will add up to all running threads
and finally require more RAM than the suggested utility thread.

Before abolishing the use of timer callbacks for network timing, I'd
like to hear your opinions.

Another modification of the Nut/OS kernel, that had been suggested more
than once is thread local storage. If timer callbacks are not executed
in the same context under which the timer had been created, then the
callback routines won't be able to make use of this local storage.

A bit of Nut/OS history: Initially timer callbacks had been executed in
interrupt context. While removing all non-deterministic critical
sections, it became clear, that these callbacks can't run in interrupt
context any longer and elapsed timer processing was shifted to the
context switcher. While improving the overall responsiveness of the
kernel, this change delayed timer processing to the next context switch.
This resulted in a lot of trouble for several existing applications,
which relied on exact timings. If we want to make sure now, that timer
callbacks are called only when the related thread gains control, the
delay will increase again. I'm not sure about its impact. Furthermore,
this would require significant changes, because timers will be bound to
the thread and are no longer global. Ending the thread will destroy all
associated timers.

As usual, all comments are most welcome.

Harald