Re: [ECOS] POSIX timer callback context

[Nick Garnett <nickg at ecoscentric dot com>]

Dan Jakubiec <djakubiec@yahoo.com> writes:

> Hi Nick,
> 
> Okay, I see what you're saying.  I had to dig into
> this a little more to realize that the eCos POSIX
> implementation really treats the whole system as one
> single process, with each task just being its own
> thread within that process.  So in effect, signal
> handling is shared amoung all "tasks" in the system.

Exactly. In POSIX terms we are attempting to conform to the POSIX
1003.13 Minimal and Realtime Controller profiles. 

> 
> However, it seems to me that timer signals would be
> more useful if an attempt was made to deliver them
> back to the thread that set the timer.  Consider the
> scenario where you have N instances of the same task
> running in parallel, each wanting to be woken up by
> their own independent timers.

In which case each timer should deliver a different signal which is
unmasked in the appropriate thread.

> It seems like an argument could be made that setting a
> timer is an "action attributable to a particular
> thread".

That would be a perverse reading of the specification. 

It is quite possible for the timer to be set up in the main thread but
handled in some other thread. Fixing the timer to signal only the
thread that created it is the wrong thing to do. Also, what happens if
the thread that created the timer has exited when the timer triggers?
What happens if a different thread calls timer_settime() on the timer,
does that thread then become the target?  What happens if
timer_settime() is called from a signal handler running on some
third-party thread?

> Last night I enhanced the POSIX timer code
> to record the thread that called timer_settime() in
> the timer object.  Then, when the timer goes off, it
> tries to deliver the signal to that thread first.  The
> changes were fairly minor and they seemed to do what I
> want.

If you want to modify the behavior of timers in your own copy of eCos
then feel free. However, I would not be happy to see it changed, or
even a configuration option added, to the generic sources. If we want
to claim POSIX compliance then we should not have non-standard options
that significantly change the expected semantics of the underlying
primitives. We are really not at liberty to make arbitrary changes to
the specification.

> 
> So my question for you is: do you think this is a
> reasonable way to handle timer signal delivery?  Do
> you see any problems with this?

It might just be acceptable to add a SIGEV_SIGNAL_THREAD that adds a
pthread_t object to the sigevent structure. POSIX allows extensions of
this type to be added. However, there is still the difficulty of what
happens if the target thread has exited when the timer triggers.

However, POSIX already provides a perfectly good mechanism for doing
this. There would have to be very compelling reasons to add something
new to duplicate this functionality.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss