svn commit: r204413 - head/sys/kern

[Jilles Tjoelker]

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