From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21391 invoked by alias); 2 Nov 2003 23:19:40 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 21383 invoked from network); 2 Nov 2003 23:19:39 -0000 Received: from unknown (HELO web21210.mail.yahoo.com) (216.136.175.253) by sources.redhat.com with SMTP; 2 Nov 2003 23:19:39 -0000 Message-ID: <20031102231938.53524.qmail@web21210.mail.yahoo.com> Received: from [65.83.223.20] by web21210.mail.yahoo.com via HTTP; Sun, 02 Nov 2003 15:19:38 PST Date: Sun, 02 Nov 2003 23:19:00 -0000 From: Dan Jakubiec To: Nick Garnett Cc: ecos-discuss@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] POSIX timer callback context X-SW-Source: 2003-11/txt/msg00005.txt.bz2 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 wrote: > Dan Jakubiec 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