Re: [ECOS] POSIX timer callback context

[Nick Garnett <nickg@ecoscentric.com>]

Dan Jakubiec <djakubiec@yahoo.com> writes:

> 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)?

Right, I hadn't quite grasped what you were talking about. That is a
somewhat more acceptable way of behaving. I guess I should have taken
a look at the patch before now :-/

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

I think, in principle, your idea is fine, and a patch that did this
would probably be acceptable. However, there are a couple of things
that I would like to see fixed before I would be happy with it:

1. The whole functionality should be controlled by a config
   option. That way users for whom this behavior is wrong can turn it
   off.

2. The implementation in your patch would have problems if the caller
   thread has exited when the timer triggers. In that case it would
   end up accessing a pthread_info object that could have been freed
   or reallocated to something else. A better approach would be to
   store a pthread_t and use pthread_info_id() to validate it and
   fetch the pthread_info pointer.

If you were to make those changes, add a ChangeLog entry and post it
to the patches list, I think it would be accepted.


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