From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19469 invoked by alias); 31 Oct 2003 18:09:04 -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 19279 invoked from network); 31 Oct 2003 18:09:01 -0000 Received: from unknown (HELO anchor-post-34.mail.demon.net) (194.217.242.92) by sources.redhat.com with SMTP; 31 Oct 2003 18:09:01 -0000 Received: from calivar.demon.co.uk ([212.228.213.211] helo=miso.calivar.com) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1AFdhk-00006p-0Y; Fri, 31 Oct 2003 18:09:00 +0000 Received: from miso.calivar.com (miso.calivar.com [127.0.0.2]) by miso.calivar.com (Postfix) with ESMTP id 53A4028DF45; Fri, 31 Oct 2003 18:08:58 +0000 (GMT) To: Dan Jakubiec Cc: ecos-discuss@sources.redhat.com References: <20031030165959.7772.qmail@web21204.mail.yahoo.com> From: Nick Garnett Date: Fri, 31 Oct 2003 18:09:00 -0000 In-Reply-To: <20031030165959.7772.qmail@web21204.mail.yahoo.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] POSIX timer callback context X-SW-Source: 2003-10/txt/msg00512.txt.bz2 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 -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss