[ECOS] POSIX timer callback context

[ECOS] POSIX timer callback context

[Dan Jakubiec]

I'm using a POSIX timer in my application that I
created with timer_create().  It is configured to
generate a SIGUSR1 signal when the timer expires, and
to call a signal handler installed by my app's thread.
 I also have several different tasks running that were
all created with pthread_create().

When the timer expires, the signal handler gets
executed, but it appears to be executing in a another
thread's context (i.e. pthread_self() returns the
handle for one of my other threads).  Furthermore, the
thread that installed the handler is waiting in a
pselect() call that never gets interrupted with EINTR.

This seems like a bug to me, but I wanted to pass this
by the group before fixing it to make sure I wasn't
missing anything.  Seems like there is a bit of a grey
area in the POSIX docs about whether signals get
delivered to the "process" or one of its "threads". 
However, it seems that in eCos it would only make
sense to deliver signals to the calling thread itself.

Does anyone have any background info on the eCos
implementation of POSIX timers, or an opinion on how
POSIX timer callbacks should be processed?

--
Dan Jakubiec
Systech Corp

__________________________________
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

Re: [ECOS] POSIX timer callback context

[Nick Garnett]

Dan Jakubiec <djakubiec@yahoo.com> writes:

> I'm using a POSIX timer in my application that I
> created with timer_create().  It is configured to
> generate a SIGUSR1 signal when the timer expires, and
> to call a signal handler installed by my app's thread.
>  I also have several different tasks running that were
> all created with pthread_create().
> 
> When the timer expires, the signal handler gets
> executed, but it appears to be executing in a another
> thread's context (i.e. pthread_self() returns the
> handle for one of my other threads).  Furthermore, the
> thread that installed the handler is waiting in a
> pselect() call that never gets interrupted with EINTR.
> 
> This seems like a bug to me, but I wanted to pass this
> by the group before fixing it to make sure I wasn't
> missing anything.  Seems like there is a bit of a grey
> area in the POSIX docs about whether signals get
> delivered to the "process" or one of its "threads". 
> However, it seems that in eCos it would only make
> sense to deliver signals to the calling thread itself.
> 
> Does anyone have any background info on the eCos
> implementation of POSIX timers, or an opinion on how
> POSIX timer callbacks should be processed?

This is not a bug. The POSIX spec is fairly clear that these are
process-wide signals that will be delivered to any thread that has the
signal unmasked. There are lots of problems with doing thread-specific
signals here that the POSIX committee decided to avoid by
side-stepping the problem.

If you want to direct the signal to a specific thread then just make
sure that that thread is the only one with the signal unmasked. The
best way to ensure this is to mask it in the signal mask of main()
before creating any other threads, which will then inherit main()'s
mask, and unmask it in the target thread.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

Re: [ECOS] POSIX timer callback context

[Dan Jakubiec]

[-- Attachment #1: Type: text/plain, Size: 4103 bytes --]

Hi Nick,

Okay, I see what you're saying.  I had to dig into
this a little more to realize that the eCos POSIX
implementation really treats the whole system as one
single process, with each task just being its own
thread within that process.  So in effect, signal
handling is shared amoung all "tasks" in the system.

However, it seems to me that timer signals would be
more useful if an attempt was made to deliver them
back to the thread that set the timer.  Consider the
scenario where you have N instances of the same task
running in parallel, each wanting to be woken up by
their own independent timers.

POSIX has this to say about signal delivery:

---POSIX---
At the time of generation, a determination shall be
made whether the signal has been generated for the
process or for a specific thread within the process.
Signals which are generated by some action
attributable to a particular thread, such as a
hardware fault, shall be generated for the thread that
caused the signal to be generated. Signals that are
generated in association with a process ID or process
group ID or an asynchronous event, such as terminal
activity, shall be generated for the process.
---POSIX---


It seems like an argument could be made that setting a
timer is an "action attributable to a particular
thread".  Last night I enhanced the POSIX timer code
to record the thread that called timer_settime() in
the timer object.  Then, when the timer goes off, it
tries to deliver the signal to that thread first.  The
changes were fairly minor and they seemed to do what I
want.

So my question for you is: do you think this is a
reasonable way to handle timer signal delivery?  Do
you see any problems with this?

I've attached a diff of my (pending) changes for your
reference if you're interested.

Thanks,

---
Dan Jakubiec
Systech Corp





--- Nick Garnett <nickg@ecoscentric.com> wrote:
> Dan Jakubiec <djakubiec@yahoo.com> writes:
> 
> > I'm using a POSIX timer in my application that I
> > created with timer_create().  It is configured to
> > generate a SIGUSR1 signal when the timer expires,
> and
> > to call a signal handler installed by my app's
> thread.
> >  I also have several different tasks running that
> were
> > all created with pthread_create().
> > 
> > When the timer expires, the signal handler gets
> > executed, but it appears to be executing in a
> another
> > thread's context (i.e. pthread_self() returns the
> > handle for one of my other threads).  Furthermore,
> the
> > thread that installed the handler is waiting in a
> > pselect() call that never gets interrupted with
> EINTR.
> > 
> > This seems like a bug to me, but I wanted to pass
> this
> > by the group before fixing it to make sure I
> wasn't
> > missing anything.  Seems like there is a bit of a
> grey
> > area in the POSIX docs about whether signals get
> > delivered to the "process" or one of its
> "threads". 
> > However, it seems that in eCos it would only make
> > sense to deliver signals to the calling thread
> itself.
> > 
> > Does anyone have any background info on the eCos
> > implementation of POSIX timers, or an opinion on
> how
> > POSIX timer callbacks should be processed?
> 
> This is not a bug. The POSIX spec is fairly clear
> that these are
> process-wide signals that will be delivered to any
> thread that has the
> signal unmasked. There are lots of problems with
> doing thread-specific
> signals here that the POSIX committee decided to
> avoid by
> side-stepping the problem.
> 
> If you want to direct the signal to a specific
> thread then just make
> sure that that thread is the only one with the
> signal unmasked. The
> best way to ensure this is to mask it in the signal
> mask of main()
> before creating any other threads, which will then
> inherit main()'s
> mask, and unmask it in the target thread.
> 
> 
> -- 
> 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/

[-- Attachment #2: timer.pat --]
[-- Type: application/octet-stream, Size: 2437 bytes --]

Index: packages/compat/posix/current/src/time.cxx
===================================================================
RCS file: /cvs/ecos/ecos/packages/compat/posix/current/src/time.cxx,v
retrieving revision 1.9
diff -u -r1.9 time.cxx
--- packages/compat/posix/current/src/time.cxx	31 Jan 2003 11:53:14 -0000	1.9
+++ packages/compat/posix/current/src/time.cxx	29 Oct 2003 16:59:43 -0000
@@ -105,6 +105,7 @@
     cyg_bool            pending;        // is expiry pending?
     int                 overrun;        // Overrun count
     struct sigevent     sigev;          // Sigevent to raise on expiry
+    pthread_info        *caller;        // Thread object that set the timer
     
     // Space for alarm object
     cyg_uint8           alarm_obj[sizeof(Cyg_Alarm)];
@@ -273,7 +274,23 @@
             sigemptyset( &mask );
             sigaddset( &mask, timer->sigev.sigev_signo );
             cyg_posix_signal_sigwait();
-            cyg_posix_pthread_release_thread( &mask );
+
+            // Wake up a thread to handle the signal.  Give preference
+            // to the thread that initially set the timer.
+            if ((timer->caller != NULL) &&
+                (timer->caller->state <= PTHREAD_STATE_RUNNING) &&
+                ((mask & ~timer->caller->sigmask) != 0))
+            {
+                // The original caller can service at least one of
+                // the pending signals.  Interrupt its current wait
+                // and make its ASR pending.
+                timer->caller->thread->set_asr_pending();
+                timer->caller->thread->release();
+
+            } else {
+                // Find another thread that can handle the signal(s).
+                cyg_posix_pthread_release_thread( &mask );
+            }
         }
         else if( timer->sigev.sigev_notify == SIGEV_THREAD )
         {
@@ -439,6 +456,7 @@
 
     timer->armed        = false;
     timer->overrun      = 0;
+    timer->caller       = NULL;
 
     *timer_id = timer->id;
     
@@ -535,6 +553,9 @@
             // If the ABSTIME flag is not set, add the current time
             if( (flags & TIMER_ABSTIME) == 0 )
                 trigger += Cyg_Clock::real_time_clock->current_value();
+
+            // Record the preferred thread context for signal delivery
+            timer->caller = pthread_self_info();
 
             // Set the alarm running.
             timer->alarm->initialize( trigger, interval );

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

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

Re: [ECOS] POSIX timer callback context

[Nick Garnett]

Dan Jakubiec <djakubiec@yahoo.com> writes:

> Hi Nick,
> 
> Okay, I see what you're saying.  I had to dig into
> this a little more to realize that the eCos POSIX
> implementation really treats the whole system as one
> single process, with each task just being its own
> thread within that process.  So in effect, signal
> handling is shared amoung all "tasks" in the system.

Exactly. In POSIX terms we are attempting to conform to the POSIX
1003.13 Minimal and Realtime Controller profiles. 

> 
> However, it seems to me that timer signals would be
> more useful if an attempt was made to deliver them
> back to the thread that set the timer.  Consider the
> scenario where you have N instances of the same task
> running in parallel, each wanting to be woken up by
> their own independent timers.

In which case each timer should deliver a different signal which is
unmasked in the appropriate thread.

> It seems like an argument could be made that setting a
> timer is an "action attributable to a particular
> thread".

That would be a perverse reading of the specification. 

It is quite possible for the timer to be set up in the main thread but
handled in some other thread. Fixing the timer to signal only the
thread that created it is the wrong thing to do. Also, what happens if
the thread that created the timer has exited when the timer triggers?
What happens if a different thread calls timer_settime() on the timer,
does that thread then become the target?  What happens if
timer_settime() is called from a signal handler running on some
third-party thread?

> Last night I enhanced the POSIX timer code
> to record the thread that called timer_settime() in
> the timer object.  Then, when the timer goes off, it
> tries to deliver the signal to that thread first.  The
> changes were fairly minor and they seemed to do what I
> want.

If you want to modify the behavior of timers in your own copy of eCos
then feel free. However, I would not be happy to see it changed, or
even a configuration option added, to the generic sources. If we want
to claim POSIX compliance then we should not have non-standard options
that significantly change the expected semantics of the underlying
primitives. We are really not at liberty to make arbitrary changes to
the specification.

> 
> So my question for you is: do you think this is a
> reasonable way to handle timer signal delivery?  Do
> you see any problems with this?

It might just be acceptable to add a SIGEV_SIGNAL_THREAD that adds a
pthread_t object to the sigevent structure. POSIX allows extensions of
this type to be added. However, there is still the difficulty of what
happens if the target thread has exited when the timer triggers.

However, POSIX already provides a perfectly good mechanism for doing
this. There would have to be very compelling reasons to add something
new to duplicate this functionality.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

Re: [ECOS] POSIX timer callback context

[Dan Jakubiec]

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)?

In terms of using a different signal for each
thread...  Our application has 24 identical threads
running on 24 different serial ports.  Each
application loop is driven by a pselect() call and has
its own timer.  There simply are not enough signals to
give each thread its own signal.

Giving preference to the caller of timer_settime()
seems to make signal delivery a little more logical
(at least in this case) and doesn't violate or change
any of the POSIX rules.  The scenarios you described
would still behave the same way.

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?

Thanks,

--
Dan Jakubiec
Systech Corp

--- Nick Garnett <nickg@ecoscentric.com> wrote:
Dan Jakubiec <djakubiec@yahoo.com> writes:

> Hi Nick,
> 
> Okay, I see what you're saying.  I had to dig into
> this a little more to realize that the eCos POSIX
> implementation really treats the whole system as one
> single process, with each task just being its own
> thread within that process.  So in effect, signal
> handling is shared amoung all "tasks" in the system.

Exactly. In POSIX terms we are attempting to conform
to the POSIX
1003.13 Minimal and Realtime Controller profiles. 

> 
> However, it seems to me that timer signals would be
> more useful if an attempt was made to deliver them
> back to the thread that set the timer.  Consider the
> scenario where you have N instances of the same task
> running in parallel, each wanting to be woken up by
> their own independent timers.

In which case each timer should deliver a different
signal which is
unmasked in the appropriate thread.

> It seems like an argument could be made that setting
a
> timer is an "action attributable to a particular
> thread".

That would be a perverse reading of the specification.


It is quite possible for the timer to be set up in the
main thread but
handled in some other thread. Fixing the timer to
signal only the
thread that created it is the wrong thing to do. Also,
what happens if
the thread that created the timer has exited when the
timer triggers?
What happens if a different thread calls
timer_settime() on the timer,
does that thread then become the target?  What happens
if
timer_settime() is called from a signal handler
running on some
third-party thread?

> Last night I enhanced the POSIX timer code
> to record the thread that called timer_settime() in
> the timer object.  Then, when the timer goes off, it
> tries to deliver the signal to that thread first. 
The
> changes were fairly minor and they seemed to do what
I
> want.

If you want to modify the behavior of timers in your
own copy of eCos
then feel free. However, I would not be happy to see
it changed, or
even a configuration option added, to the generic
sources. If we want
to claim POSIX compliance then we should not have
non-standard options
that significantly change the expected semantics of
the underlying
primitives. We are really not at liberty to make
arbitrary changes to
the specification.

> 
> So my question for you is: do you think this is a
> reasonable way to handle timer signal delivery?  Do
> you see any problems with this?

It might just be acceptable to add a
SIGEV_SIGNAL_THREAD that adds a
pthread_t object to the sigevent structure. POSIX
allows extensions of
this type to be added. However, there is still the
difficulty of what
happens if the target thread has exited when the timer
triggers.

However, POSIX already provides a perfectly good
mechanism for doing
this. There would have to be very compelling reasons
to add something
new to duplicate this functionality.


-- 
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

Re: [ECOS] POSIX timer callback context

[Nick Garnett]

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


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

Re: [ECOS] POSIX timer callback context

[Dan Jakubiec]

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

Re: [ECOS] POSIX timer callback context

[mbs]

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

Re: [ECOS] POSIX timer callback context

[Dan Jakubiec]

Mark,

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

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
support.

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
threads.

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
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

Re: [ECOS] POSIX timer callback context

[Dan Jakubiec]

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

Re: [ECOS] POSIX timer callback context

[mbs]

I'm not really resistant to it, (nor should my resistance really be a factor 
as I have never contributed one line to ECOS, I am evaluating it as a 
platform for some future work, but I have done a fair amount of POSIX related 
work in my company's proprietary RTOS and we ran into similar issues.) I just 
wanted to point out one possible issue.  in fact, I wish POSIX were 
explicitely spec'd to do what you've suggested as well as many other thread 
sanity behaviors WRT signals.  I think this would make a great config option 
(something like "treat threads as procs WRT signals").

In general, whenever we (my company) have been working on a standards related 
API, we have always strived to folow the principle of least surprise, i.e. 
our OS shouldn't surprise our customers with unusual behavior, even when that 
behavior is technically legal in the spec and we think that the behavior is 
benign or even beneficial.

another interesting hole in the POSIX spec WRT timers is calling 
timer_settime() after timer expiration, but before completion of the signal 
handler.  this is "undefined" in POSIX and every OS does something a little 
different.  it is technically legal for the OS to panic in this situation, 
but evil (assert I don't know what ecos does here). this is most commonly 
seen when someone has siglongjmp()'d away from the handler.


On Monday 03 November 2003 12:57, Dan Jakubiec wrote:
> Mark,
>
> Yes, I see your point.  From that perspective, perhaps
> this patch isn't really suitable for public
> submission.
>
> 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
> support.
>
> 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
> threads.
>
> 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.

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