[ECOS] POSIX timer callback context

Dan Jakubiec djakubiec@yahoo.com
Mon Nov 3 17:57:00 GMT 2003


Yes, I see your point.  From that perspective, perhaps
this patch isn't really suitable for public

Our app is actually designed to be run as multiple
processes, not threads.  The only real reason I went
down this road is because we have 24 threads and not
enough signals.  It seemed to me that since the signal
delivery behavior is not really defined, that making
it more deterministic wouldn't break anything, and
would be a clean way to side-step the issue until we
could implement more full-fledged POSIX process

Since our signal usage is minimal (we just use them to
wake up pselect() calls), our application is still
portable, with the qualification that in a different
environment our tasks get started as processes, not

In any case, my orginal thinking was that providing
some level of determinism to the timers provides the
app writer with some more options and, technically
speaking, doesn't really change or break any existing
behavior (since it's undefined to begin with).  Also,
the POSIX spec made vague reference to "actions
attributable to a particular thread", which made the
whole thing seem rather logical.

So I don't know. At this point I guess I'm on the
fence about whether to submit the patch or not.  I
understand the resistance coming from you and Nick on
the whole issue, and I concur with the "funny feeling"
of it all.  My thinking is that it doesn't hurt
anything and may help someone else in a similar
situation to mine, but I'm also okay with just keeping
the patch private to our source base.

What do you guys think?  Any strong opinions on how to
proceed from here?

Thanks again for all the input.

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

Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list