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

[Nathan Moore]

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


Close to my idea.

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


Unless something has changed recently that I haven't seen (I'm on older
version of Nut)
there is another problem.  While timers are no longer executed in interrupt
context they still
have some of the same constraints as interrupt handlers.
Particularly they should never yield.  If they do then the context switching
code becomes
reentrant.  Then bad things happen.  The run queue and the timer list would
all have to
be handled much more carefully.

I'm not sure what running a timer thread in such a way that it has access to
the context of the
thread which created the timer gets you in general cases (in special cases
it may be handled by
the application as part of the timer's *arg).  There is no guarantee that
the thread that created
the timer will still be around when the timer fires.

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



This brings up the recently discussed locality of errno as well as thread
local pages
when paged ram is available.   While thread local storage being visible to
the timer
may be a win, it still becomes tricky since the thread might have exited by
the time
the timer fires.

I had considered creating temporary threads to handle timer like situations
when the
limitation of timer context were troublesome, but extra threads introduce
their own
problems.

Nathan