]> git.neil.brown.name Git - history.git/commit
[PATCH] thread-exec-2.5.34-B1, BK-curr
authorIngo Molnar <mingo@elte.hu>
Sun, 15 Sep 2002 04:20:59 +0000 (21:20 -0700)
committerLinus Torvalds <torvalds@home.transmeta.com>
Sun, 15 Sep 2002 04:20:59 +0000 (21:20 -0700)
commit63540ceac6d79d7703dfe6e2c161f342a03f8a11
tree4161bdcd93d5a84d321dc1770b45ade6271d6668
parent7cd0a691fff9f123800487748a327f618b62a667
[PATCH] thread-exec-2.5.34-B1, BK-curr

This implements one of the last missing POSIX threading details - exec()
semantics.  Previous kernels had code that tried to handle it, but that
code had a number of disadvantages:

 - it only worked if the exec()-ing thread was the thread group leader,
   creating an assymetry. This does not work if the thread group leader
   has exited already.

 - it was racy: it sent a SIGKILL to every thread in the group but did not
   wait for them to actually process the SIGKILL. It did a yield() but
   that is not enough. All 'other' threads have to finish processing
   before we can continue with the exec().

This adds the same logic, but extended with the following enhancements:

 - works from non-leader threads just as much as the thread group leader.

 - waits for all other threads to exit before continuing with the exec().

 - reuses the PID of the group.

It would perhaps be a more generic approach to add a new syscall,
sys_ungroup() - which would do largely what de_thread() does in this
patch.

But it's not really needed now - posix_spawn() is currently implemented
via starting a non-CLONE_THREAD helper thread that does a sys_exec().
There's no API currently that needs a direct exec() from a thread - but
it could be created (such as pthread_exec_np()).  It would have the
advantage of not having to go through a helper thread, but the
difference is minimal.
fs/exec.c
include/linux/sched.h
kernel/exit.c
kernel/fork.c
kernel/signal.c