On Sun, 9 Jan 2022 at 16:51, Warner Losh <i...@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 <s...@freebsd.org> > Signed-off-by: Kyle Evans <kev...@freebsd.org> > Signed-off-by: Warner Losh <i...@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
