Skip site navigation (1)Skip section navigation (2)
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>