Re: [ECOS] POSIX timer callback context

[mbs <mbs at mc dot com>]

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!!  **
\**************************************************/

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