svn commit: r204413 - head/sys/kern
jilles at stack.nl
Wed Mar 3 22:06:40 UTC 2010
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
It is not that important, also given apparent plans to show signal
information in procstat(1) which will be easier to use.
More information about the svn-src-all