Re: [ECOS] POSIX timer callback context

[Dan Jakubiec <djakubiec at yahoo dot com>]

Hi Nick,

Thanks for the feedback.  I see the motivation behind
making this a configurable option: technically there
are two different behaviors that one could choose from
here.

But I guess I'm trying to figure out what the option
would really be asking you to choose.  POSIX doesn't
really define a behavior here and the current
implementation just arbitrarily returns any thread
that  can service the request.  In other words, there
is currently no behavior here that a user application
could really depend on (other than perhaps that a
"randomly" chosen thread will receive the
notification).  Although the new behavior is more
deterministic, it neverthless doesn't really change
the expected behavior for *existing* apps.  They still
will "get what they get" with respect to which thread
gets the notification.


As for your point #2 about the thread exitting: yes
you're right.  I mistakenly thought the pthread_info's
were stored in a static table.  Turns out they are
allocated on the process's stack.  I will look at
fixing it in the way you recommended.

Thanks,

--
Dan Jakubiec
Systech Corp



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


__________________________________
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