lkml.org 
[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: CLONE_PDEATHKILL introduction
From
Date
"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> Pavel Krauz writes:
> > I would like to propose CLONE_PDEATHKILL option.
> > This option just fills the gap that exists when the thread
> > is started and before the prctl can be called to instruct
> > the child to receive signal when parent dies. So with this
> > option the clone/prctl combination would be complete.
>
> How about allowing any signal? The clone() caller could OR in
> the signal number shifted left by 25 bits.

I still don't see what is wrong with something like

/* ... block SIGWHATEVER ... */
prctl(PR_SET_PDEATHSIG, SIGWHATEVER);
/* Were we orphaned before the prctl? */
if (__getppid() == 1)
__kill(__getpid(), SIGWHATEVER);
/* ... now unblock SIGWHATVER ... */

(If performance is a real issue, the block/unblock can be avoided by
using an atomic test-and-set, in which case just two system calls are
needed.)

We have the functionality already, so why take up valuable bits in the
clone() flags word?


David Wragg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.050 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site