On Sun, Feb 28, 2010 at 01:15:08PM +0200, Kostik Belousov wrote: > 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) ? Yes. Unfortunately the signal keywords are pretty poorly documented. > > 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 ? To make non-threaded output of multi-threaded processes slightly more consistent. It is not that important, also given apparent plans to show signal information in procstat(1) which will be easier to use. -- Jilles Tjoelker _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"