From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20583 invoked by alias); 3 Nov 2003 17:57:42 -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 20576 invoked from network); 3 Nov 2003 17:57:41 -0000 Received: from unknown (HELO web21209.mail.yahoo.com) (216.136.175.167) by sources.redhat.com with SMTP; 3 Nov 2003 17:57:41 -0000 Message-ID: <20031103175740.75652.qmail@web21209.mail.yahoo.com> Received: from [65.83.223.20] by web21209.mail.yahoo.com via HTTP; Mon, 03 Nov 2003 09:57:40 PST Date: Mon, 03 Nov 2003 17:57:00 -0000 From: Dan Jakubiec To: mbs , Nick Garnett Cc: ecos-discuss@sources.redhat.com In-Reply-To: <200311031315.IAA20166@mc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] POSIX timer callback context X-SW-Source: 2003-11/txt/msg00017.txt.bz2 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 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