Date: Wed, 3 Mar 2010 23:06:39 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r204413 - head/sys/kern Message-ID: <20100303220639.GA52066@stack.nl> In-Reply-To: <20100228111508.GN2489@deviant.kiev.zoral.com.ua> References: <201002271532.o1RFWnCp099462@svn.freebsd.org> <20100227220854.GB77656@stack.nl> <20100228111508.GN2489@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100303220639.GA52066>