This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: POSIX timer callback context
- From: Dan Jakubiec <djakubiec at yahoo dot com>
- To: Nick Garnett <nickg at ecoscentric dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Sun, 2 Nov 2003 15:19:38 -0800 (PST)
- Subject: Re: [ECOS] POSIX timer callback context
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