Date: Sat, 27 Feb 2010 23:08:54 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Konstantin Belousov <kib@FreeBSD.org> 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: <20100227220854.GB77656@stack.nl> In-Reply-To: <201002271532.o1RFWnCp099462@svn.freebsd.org> References: <201002271532.o1RFWnCp099462@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. 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. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100227220854.GB77656>