On Thu, Jan 13, 2022 at 1:37 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> 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