On 01/22/21 18:58, Max Reitz wrote:
> On 22.01.21 17:38, Laszlo Ersek wrote:
>> (1) With SIGUSR2 permanently dedicated to "coroutine-sigaltstack.c", the
>> comment on the qemu_init_main_loop() declaration, in
>> "include/qemu/main-loop.h", also needs to be updated. SIGUSR2 is no
>> longer a "free for thread-internal usage" signal.
>
> It’s possible that I haven’t understood that comment, but I haven’t
> adjusted it because I didn’t interpret it to mean that the signals
> listed there were free to use. For example, SIGUSR1 (aliased to
> SIG_IPI) is generated by cpus_kick_thread() and caught by KVM and HVF,
> so it doesn’t seem like it would be free for thread-internal usage either.
>
> Instead, I understood it to mean that the signals listed there do not
> have to be blocked by non-main threads, because it is OK for non-main
> threads to catch them. I can’t think of a reason why SIGUSR2 should be
> blocked by any thread, so I decided not to change the comment.
>
> But perhaps I just didn’t understand the whole comment. That’s
> definitely possible, given that I don’t even see a place where non-main
> threads would block the signals not listed there.
Upon re-reading the comment, and also looking at the
qemu_init_main_loop() and qemu_signal_init() function definitions, I now
think that the
consider these signals to be safe
language simply means that the main thread does not intend to handle the
listed signals.
Your SIG_IPI example is great, because, while SIG_IPI does not satisfy
my original characterization ("free for thread-internal usage"), it does
satisfy "not handled by the main thread".
If we accept that interpretation, then we shouldn't in fact modify the
comment on qemu_init_main_loop(). Because, our dedicating SIGUSR2 to
coroutine-sigaltstack remains consistent with the main thread not
intending to handle SIGUSR2.
Put differently, what we're doing with SIGUSR2 now -- which is on the
list in the comment -- has been done *earlier* with SIG_IPI -- SIGUSR1,
also on the list --, namely, using the signal for a particular
inter-thread, or intra-thread, purpose, while making sure the main
thread does not intend to handle the signal.
Thanks
Laszlo
