[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o96napgb.fsf@oldenburg2.str.redhat.com>
Date: Wed, 06 Mar 2019 18:21:40 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: sigaltstack for implementation-internal signals?
* 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
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.
