All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Simon Holm Thøgersen" <odie@cs.aau.dk>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>,
	Jean-Paul Calderone <exarkun@twistedmatrix.com>
Subject: Allow signaling a process by all its thread ids?
Date: Fri, 22 May 2009 00:16:19 +0200	[thread overview]
Message-ID: <1242944179.10298.11.camel@odie.local> (raw)

There is a bug report at https://bugs.launchpad.net/bugs/341239 where
the question is asked. Should it be possible to signal a process with
kill(2) by passing any of the thread ids belong to the process as
argument to kill?

Current behaviour allows that but the reporter argues that it shouldn't
be allowed by the following argument:

"I'm no expert in interpreting POSIX.  A casual (but careful) reading of
POSIX 1003.1-2004 suggests that this isn't the intended behavior.  It is
implied in a few places, most notably the getpid[1] documentation, that
a process has only one PID (by use of the definite article when
referring to it - ie, "the process ID").  The kill function[2] operates
on "a process or a group of processes".  It sends a signal "to the
process whose process ID is equal to pid".  Combined with the previous
point, this suggests there should be only one process ID which can be
passed to kill to send a signal to a particular process.

It may be that POSIX is weakly worded enough that either allowing or
disallowing this behavior is valid.  I think that allowing it is a
violation of POSIX, but I can find no single, explicit, direct statement
in POSIX to back this up.

There is at least one other argument to disallow this behavior even if
it is not technically illegal.  Consider the traditional, widespread
convention of pid files.  This behavior drastically reduces their
utility, as it greatly increases the chance of PID collisions, a case in
which it is difficult to automatically (that is, without human
intervention) recognize that a pid file no longer corresponds to a
running process which created it.  This is the case in which I
encountered the behavior - when it repeatedly caused services not to
restart because they encountered a thread of another process and
misinterpreted it to mean the service was already running.

I hope this is convincing.  If not, what kind of argument would be?

[1]: http://www.opengroup.org/onlinepubs/009695399/functions/getpid.html
[2]: http://www.opengroup.org/onlinepubs/009695399/functions/kill.html"


Simon Holm Thøgersen


             reply	other threads:[~2009-05-21 22:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21 22:16 Simon Holm Thøgersen [this message]
2009-05-21 22:54 ` Allow signaling a process by all its thread ids? Alan Cox
2009-05-21 23:11   ` Chris Friesen
2009-05-21 22:57 ` Chris Friesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1242944179.10298.11.camel@odie.local \
    --to=odie@cs.aau.dk \
    --cc=exarkun@twistedmatrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.