Date: Sun, 28 Feb 2010 13:15:08 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> 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: <20100228111508.GN2489@deviant.kiev.zoral.com.ua> In-Reply-To: <20100227220854.GB77656@stack.nl> References: <201002271532.o1RFWnCp099462@svn.freebsd.org> <20100227220854.GB77656@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100228111508.GN2489>