Messages in this thread | | | Subject | Re: CLONE_PDEATHKILL introduction | From | David Wragg <> | Date | 12 Mar 2000 12:26:30 +0000 |
| |
"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/
| |