From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13936 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: sigaltstack for implementation-internal signals? Date: Wed, 06 Mar 2019 18:21:40 +0100 Message-ID: <87o96napgb.fsf@oldenburg2.str.redhat.com> References: <20190305155719.GO23599@brightrain.aerifal.cx> <87tvggb1r1.fsf@oldenburg2.str.redhat.com> <20190306155421.GR23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="36224"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13952-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 06 18:21:58 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h1aEw-0009L8-6K for gllmg-musl@m.gmane.org; Wed, 06 Mar 2019 18:21:58 +0100 Original-Received: (qmail 6078 invoked by uid 550); 6 Mar 2019 17:21:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 6057 invoked from network); 6 Mar 2019 17:21:55 -0000 In-Reply-To: <20190306155421.GR23599@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 6 Mar 2019 10:54:21 -0500") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 06 Mar 2019 17:21:43 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:13936 Archived-At: * Rich Felker: > For pthread_cancel, it's asynchronous. The signal can be blocked if > the cancellation signal handler has already run and determined that it > should not act on cancellation (disabled or not at a cancellation > point); in that case, it re-raises the signal and leaves it pending, > so that, if the determination was made while the thread was executing > a signal handler, it can re-evaluate when the signal handler returns > (possibly into restarting a blocking syscall that's a cancellation > point). I don't see any easy way to make this synchronous with respect > to the thread calling pthread_cancel, but maybe there is by breaking > it down into cases and using more than one signal. phtread_cancel is slightly different; I think think we can send a signal for that. It can't be made synchronous because if we block the canceling thread while the canceled thread unwinds (running cancellation handlers), we will probably end up introducing deadlocks involving application locks. Thanks, Florian