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.

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.

POSIX has this to say about signal delivery:

---POSIX---
At the time of generation, a determination shall be
made whether the signal has been generated for the
process or for a specific thread within the process.
Signals which are generated by some action
attributable to a particular thread, such as a
hardware fault, shall be generated for the thread that
caused the signal to be generated. Signals that are
generated in association with a process ID or process
group ID or an asynchronous event, such as terminal
activity, shall be generated for the process.
---POSIX---


It seems like an argument could be made that setting a
timer is an "action attributable to a particular
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.

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?

I've attached a diff of my (pending) changes for your
reference if you're interested.

Thanks,

---
Dan Jakubiec
Systech Corp





--- Nick Garnett <nickg@ecoscentric.com> wrote:
> Dan Jakubiec <djakubiec@yahoo.com> writes:
> 
> > I'm using a POSIX timer in my application that I
> > created with timer_create().  It is configured to
> > generate a SIGUSR1 signal when the timer expires,
> and
> > to call a signal handler installed by my app's
> thread.
> >  I also have several different tasks running that
> were
> > all created with pthread_create().
> > 
> > When the timer expires, the signal handler gets
> > executed, but it appears to be executing in a
> another
> > thread's context (i.e. pthread_self() returns the
> > handle for one of my other threads).  Furthermore,
> the
> > thread that installed the handler is waiting in a
> > pselect() call that never gets interrupted with
> EINTR.
> > 
> > This seems like a bug to me, but I wanted to pass
> this
> > by the group before fixing it to make sure I
> wasn't
> > missing anything.  Seems like there is a bit of a
> grey
> > area in the POSIX docs about whether signals get
> > delivered to the "process" or one of its
> "threads". 
> > However, it seems that in eCos it would only make
> > sense to deliver signals to the calling thread
> itself.
> > 
> > Does anyone have any background info on the eCos
> > implementation of POSIX timers, or an opinion on
> how
> > POSIX timer callbacks should be processed?
> 
> This is not a bug. The POSIX spec is fairly clear
> that these are
> process-wide signals that will be delivered to any
> thread that has the
> signal unmasked. There are lots of problems with
> doing thread-specific
> signals here that the POSIX committee decided to
> avoid by
> side-stepping the problem.
> 
> If you want to direct the signal to a specific
> thread then just make
> sure that that thread is the only one with the
> signal unmasked. The
> best way to ensure this is to mask it in the signal
> mask of main()
> before creating any other threads, which will then
> inherit main()'s
> mask, and unmask it in the target thread.
> 
> 
> -- 
> 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/