qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 36/40] bsd-user/signal.c: implement do_sigaction


From: Peter Maydell
Subject: Re: [PATCH v2 36/40] bsd-user/signal.c: implement do_sigaction
Date: Fri, 28 Jan 2022 10:37:02 +0000

On Thu, 27 Jan 2022 at 22:46, Warner Losh <wlosh@bsdimp.com> wrote:
>
>
>
> > On Jan 24, 2022, at 6:29 PM, Warner Losh <imp@bsdimp.com> wrote:
> >
> > Implement the meat of the sigaction(2) system call with do_sigaction and
> > helper routiner block_signals (which is also used to implemement signal
> > masking so it's global).
> >
> > Signed-off-by: Stacey Son <sson@FreeBSD.org>
> > Signed-off-by: Kyle Evans <kevans@freebsd.org>
> > Signed-off-by: Warner Losh <imp@bsdimp.com>
> >
> > Pending Comments from Peter Maydell <peter.maydell@linaro.org>
> >
> > (1) in block_signals, sigprocmast
> > For linux-user we rely on sigprocmask() in a multithreaded
> > program setting the signal mask for only the calling thread,
> > which isn't POSIX-mandated. (Arguably we should use
> > pthread_sigmask() instead, but we don't for basically
> > historical reasons since linux-user is host-OS-specific anyway.)
> > Does BSD have the same "this changes this thread's signal mask"
> > semantics for sigprocmask()?
>
> FreeBSD changes this on a per-thread basis for both
> sigprocmask and pthread_sigmask(). pthread_sigmask() just
> does some extra stuff with SIGCANCEL for pthread_cancel
> support which qemu doesn’t use. They are the same. I’m inclined
> to leave it as sigprocmask() since I’m unsure what the implications
> of doing funky things for SIGCANCEL would be.

Yes, that sounds like the right thing.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]