Re: [ECOS] POSIX timer callback context

[Dan Jakubiec <djakubiec at yahoo dot com>]

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