On Sat, Feb 27, 2010 at 11:08:54PM +0100, Jilles Tjoelker wrote: > On Sat, Feb 27, 2010 at 03:32:49PM +0000, Konstantin Belousov wrote: > > Author: kib > > Date: Sat Feb 27 15:32:49 2010 > > New Revision: 204413 > > URL: http://svn.freebsd.org/changeset/base/204413 > > > Log: > > For kinfo_proc in kp->ki_siglist, return the set of the signals pending > > in the process queue when gathering information for the process, and set > > of signals pending for the thread, when gathering information for the > > thread. Previously, the sysctl returned a union of the process and some > > arbitrary thread pending set for the process, and union of the process > > and the thread pending set for the thread. > > Although the new way provides maximum information and the old way was > definitely broken for processes, I think the new way may not be what I > expect. In particular, 'ps O pending' and 'ps HO pending' now give > (usually) disjunct answers, even for single-threaded processes. I > suppose these different answers can be useful for kernel debugging, but > it should be documented. Not only for the kernel debugging. Being able to see a pending signal in the process queue means that signal delivery for the process is stopped. Change provides a capability to start analyze such situation without resorting to the kernel debugger.
More, I do not consider the change to be significant enough from the interface stability point of view, thus planning to merge it to 8. Where do you suggest to document the behaviour ? ps(1) ? > > Most interesting stuff will be in the process queue so the change will > not be very noticeable. Signals directed at threads are usually traps > (which do not stay pending very long), pthread_kill() or > SIGEV_THREAD_ID. SIGPIPE and SIGSYS (not from kill/sigqueue) may be > expected to be thread-directed but they are process-directed. Traps do not stay in the queue at all, they are delivered immediately, unless administrator ajdusted kern.forcesigexit. In the later case, I think that the process will be eventually terminated with the stack overflow. > > In 7.x, process-directed signals are often delivered directly to a > thread queue, but this usually only happens for signals that will be > delivered right away. Or rather, this happen for signal that can be queued but not blocked by choosen thread at the moment of delivery. And kernel tried to to select a thread that has the signal not blocked. > > Somewhat related, ki_sigmask could be the logical AND of all threads' > td_sigmask when gathering information for the process, instead of the > td_sigmask of the most recently created thread; fill_kinfo_aggregate() > could handle this. ki_sigmask arguably has no meaning in the process context. Do you propose this to simplify handling of a single-threaded process ?
pgpf0XsAmuC9h.pgp
Description: PGP signature
