Re: [ECOS] POSIX timer callback context

[Dan Jakubiec <djakubiec at yahoo dot com>]

Hi Nick,

Of course I agree that we shouldn't do anything
non-standard.  I was not suggesting that we restrict
the signal delivery to *only* go back to the original
thread.  I was only suggesting that when choosing
which thread gets the delivered signal, we give
*preference* to one that initially made the
timer_settime() call.  If the thread goes away or has
signals blocked or whatever, then the current
algorithm is still used to choose a different thread. 
Since the method of choosing the thread is already
largly arbitrary, it should make no real difference in
the POSIX sense.  POSIX just chooses the first
qualifying thread it finds; why not make it the one
that set the timer up in the first place (as long as
it's valid)?

In terms of using a different signal for each
thread...  Our application has 24 identical threads
running on 24 different serial ports.  Each
application loop is driven by a pselect() call and has
its own timer.  There simply are not enough signals to
give each thread its own signal.

Giving preference to the caller of timer_settime()
seems to make signal delivery a little more logical
(at least in this case) and doesn't violate or change
any of the POSIX rules.  The scenarios you described
would still behave the same way.

The SIGEV_SIGNAL_THREAD idea seems interesting, but
I'm wondering if it will really help.  Ultimately, the
problem is that I need to interrupt the pselect() call
of a paritcular thread, which can only be done with a
signal.  If any signal I send gets delivered
arbitrarily to any unblocked thread, then there is no
real way to direct the signal to a particular thread
without using different signals.  And if you have more
threads than signals, you're out of luck.

Does this make sense?

Thanks,

--
Dan Jakubiec
Systech Corp

--- Nick Garnett <nickg@ecoscentric.com> wrote:
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




__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

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