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.
I've kept the former bits (implementing queue_signal() function), but removed
the rest.
> 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.
Gotcha. That makes sense. Any reason that atomics aren't used
for this between the different routines?
Warner