[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 6 Mar 2019 13:03:28 -0500
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: musl@...ts.openwall.com
Subject: Re: sigaltstack for implementation-internal signals?
On Wed, Mar 06, 2019 at 06:21:40PM +0100, Florian Weimer wrote:
> * 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.
If not for the "re-raise a signal" aspect I described, you could do it
"synchronously". You don't have to wait for the cleanup functions to
run. Rather, you'd just wait for the target thread to exit the base
cancellation logic code, respond with an indication of what it's
doing, and get off the new stack. If acting on the cancellation, it
would modify the ucontext it's returning to with a new call frame on
it's main stack to run the unwind/cleanup in, then return.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
