* [ECOS] POSIX timer callback context @ 2003-10-28 21:09 Dan Jakubiec 2003-10-29 15:33 ` Nick Garnett 0 siblings, 1 reply; 11+ messages in thread From: Dan Jakubiec @ 2003-10-28 21:09 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-28 21:09 [ECOS] POSIX timer callback context Dan Jakubiec @ 2003-10-29 15:33 ` Nick Garnett 2003-10-29 17:04 ` Dan Jakubiec 2003-10-30 17:00 ` Dan Jakubiec 0 siblings, 2 replies; 11+ messages in thread From: Nick Garnett @ 2003-10-29 15:33 UTC (permalink / raw) To: Dan Jakubiec; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-29 15:33 ` Nick Garnett @ 2003-10-29 17:04 ` Dan Jakubiec 2003-10-30 15:32 ` Nick Garnett 2003-10-30 17:00 ` Dan Jakubiec 1 sibling, 1 reply; 11+ messages in thread From: Dan Jakubiec @ 2003-10-29 17:04 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-29 17:04 ` Dan Jakubiec @ 2003-10-30 15:32 ` Nick Garnett 0 siblings, 0 replies; 11+ messages in thread From: Nick Garnett @ 2003-10-30 15:32 UTC (permalink / raw) To: Dan Jakubiec; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-29 15:33 ` Nick Garnett 2003-10-29 17:04 ` Dan Jakubiec @ 2003-10-30 17:00 ` Dan Jakubiec 2003-10-31 18:09 ` Nick Garnett 1 sibling, 1 reply; 11+ messages in thread From: Dan Jakubiec @ 2003-10-30 17:00 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-30 17:00 ` Dan Jakubiec @ 2003-10-31 18:09 ` Nick Garnett 2003-11-02 23:19 ` Dan Jakubiec 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2003-10-31 18:09 UTC (permalink / raw) To: Dan Jakubiec; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-10-31 18:09 ` Nick Garnett @ 2003-11-02 23:19 ` Dan Jakubiec 2003-11-03 13:15 ` mbs 0 siblings, 1 reply; 11+ messages in thread From: Dan Jakubiec @ 2003-11-02 23:19 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-11-02 23:19 ` Dan Jakubiec @ 2003-11-03 13:15 ` mbs 2003-11-03 17:57 ` Dan Jakubiec 2003-11-03 18:14 ` Dan Jakubiec 0 siblings, 2 replies; 11+ messages in thread From: mbs @ 2003-11-03 13:15 UTC (permalink / raw) To: Dan Jakubiec, Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-11-03 13:15 ` mbs @ 2003-11-03 17:57 ` Dan Jakubiec 2003-11-03 18:36 ` mbs 2003-11-03 18:14 ` Dan Jakubiec 1 sibling, 1 reply; 11+ messages in thread From: Dan Jakubiec @ 2003-11-03 17:57 UTC (permalink / raw) To: mbs, Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-11-03 17:57 ` Dan Jakubiec @ 2003-11-03 18:36 ` mbs 0 siblings, 0 replies; 11+ messages in thread From: mbs @ 2003-11-03 18:36 UTC (permalink / raw) To: Dan Jakubiec, Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] POSIX timer callback context 2003-11-03 13:15 ` mbs 2003-11-03 17:57 ` Dan Jakubiec @ 2003-11-03 18:14 ` Dan Jakubiec 1 sibling, 0 replies; 11+ messages in thread From: Dan Jakubiec @ 2003-11-03 18:14 UTC (permalink / raw) To: mbs, Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-11-03 18:36 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-28 21:09 [ECOS] POSIX timer callback context Dan Jakubiec 2003-10-29 15:33 ` Nick Garnett 2003-10-29 17:04 ` Dan Jakubiec 2003-10-30 15:32 ` Nick Garnett 2003-10-30 17:00 ` Dan Jakubiec 2003-10-31 18:09 ` Nick Garnett 2003-11-02 23:19 ` Dan Jakubiec 2003-11-03 13:15 ` mbs 2003-11-03 17:57 ` Dan Jakubiec 2003-11-03 18:36 ` mbs 2003-11-03 18:14 ` Dan Jakubiec
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).