Re: [PATCH 22/30] bsd-user/signal.c: Fill in queue_signal

[Peter Maydell]

On Sun, 9 Jan 2022 at 16:51, Warner Losh <imp@bsdimp.com> wrote:
>
> Fill in queue signal implementation, as well as routines allocate and
> delete elements of the signal queue.

See reply to patch 18 for why you probably don't want to do this.

> Signed-off-by: Stacey Son <sson@FreeBSD.org>
> Signed-off-by: Kyle Evans <kevans@freebsd.org>
> Signed-off-by: Warner Losh <imp@bsdimp.com>
> ---


> +    /*
> +     * FreeBSD signals are always queued.  Linux only queues real time 
> signals.
> +     * XXX this code is not thread safe.  "What lock protects ts->sigtab?"
> +     */

ts->sigtab shouldn't need a lock, because it is per-thread,
like all of TaskState. (The TaskState structure is pointed
to by the CPUState 'opaque' field. CPUStates are per-thread;
the TaskState for a new thread's new CPUState is allocated
and initialized as part of the emulating of whatever the
"create new thread" syscall is. For Linux this is in
do_fork() for the CLONE_VM case. The TaskState for the
initial thread is allocated in main.c.) We do need to deal
with the fact that ts->sigtab can be updated by a signal
handler (which always runs in the thread corresponding to
that guest CPU): the linux-user process_pending_signals()
has been written with that in mind.

thanks
-- PMM