From owner-svn-src-head@FreeBSD.ORG Sun Feb 28 11:15:11 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74F1106566C; Sun, 28 Feb 2010 11:15:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 49F0A8FC0A; Sun, 28 Feb 2010 11:15:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1SBF9NM058363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Feb 2010 13:15:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o1SBF9m5085583; Sun, 28 Feb 2010 13:15:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o1SBF82x085582; Sun, 28 Feb 2010 13:15:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 28 Feb 2010 13:15:08 +0200 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20100228111508.GN2489@deviant.kiev.zoral.com.ua> References: <201002271532.o1RFWnCp099462@svn.freebsd.org> <20100227220854.GB77656@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BjavXC7V3ilNTWHC" Content-Disposition: inline In-Reply-To: <20100227220854.GB77656@stack.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r204413 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 11:15:11 -0000 --BjavXC7V3ilNTWHC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > > Log: > > For kinfo_proc in kp->ki_siglist, return the set of the signals pendi= ng > > 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 so= me > > arbitrary thread pending set for the process, and union of the process > > and the thread pending set for the thread. >=20 > 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) ? >=20 > 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. Traps do not stay in the queue at all, they are delivered immediately, unless administrator ajdusted kern.forcesigexit. In the later case, I think that the process will be eventually terminated with the stack overflow. >=20 > 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. Or rather, this happen for signal that can be queued but not blocked by choosen thread at the moment of delivery. And kernel tried to to select a thread that has the signal not blocked. >=20 > 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 ? --BjavXC7V3ilNTWHC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuKUDwACgkQC3+MBN1Mb4gdhwCgnnPxXM5nBrFH1FunPk0uIvI6 5uAAoPPNqAj3HJ7gr6BjKF9albywq+kI =iHuM -----END PGP SIGNATURE----- --BjavXC7V3ilNTWHC--