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: mbs <mbs at mc dot com>, Nick Garnett <nickg at ecoscentric dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Mon, 3 Nov 2003 10:14:02 -0800 (PST)
- Subject: Re: [ECOS] POSIX timer callback context
Mark,
Oops, one last thing. So yes, I agree that adding a
"convenience feature" isn't going to help anyone write
better apps. But in our case it is a functional
issue: we can't use the sigmask/multiple-signals
approach because there just aren't enough signals to
support all our threads.
So ultimately, I think the "correct" POSIX answer to
our problem is to use multiple processes. We will
probably be investigating this possibility soon since
we have other needs for process-like behavior. But in
the meantime, I was investigating this issue as a
reasonable alternative.
--
Dan Jakubiec
Systech Corp
--- mbs <mbs@mc.com> wrote:
> one big thing to think about here though, is that
> any app that relies on this
> behavior is no longer a truly portable POSIX app
> (which is the whole point of
> POSIX no?)
>
> if you want your app to be portable, you will still
> have to ensure that the
> thread which you want to handle the signal is the
> only thread with the given
> signal unmasked.
>
> if it makes ecos cleaner or smaller, then cool, but
> if you have to muck up
> the code (note, I haven't looked at the patch so am
> speaking completely
> without basis here) to add a convenience feature
> that hurts application
> portability (or makes it easier to write a
> non-portable app) then you are not
> really helping anyone.
>
> I know, the whole undefined behavior business is a
> pain, but what it really
> does (probably unintentionally) is force the app
> developer to be disciplined
> and pay attention to things like sigmasks instead of
> being sloppy and relying
> on assumptions or special behaviors of one OS.
>
> this is a capability vs. policy question and 9 out
> of 10 times, the OS should
> provide capability, and the app should decide
> policy.
>
>
> On Sunday 02 November 2003 18:19, Dan Jakubiec
> wrote:
> > 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,
>
> --
> /**************************************************\
> ** Mark Salisbury || mbs@mc.com **
> ** Thanks to all who sposored me for the Multiple **
> ** Sclerosis ride. This year we raised $4,680!! **
> \**************************************************/
__________________________________
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