svn commit: r204413 - head/sys/kern

[Kostik Belousov]

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) ?

> 
> 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.

> 
> 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.

> 
> 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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100228/c7a82e7f/attachment.pgp