yodaiken@fsmlabs.com wrote:
> > Obviously? Descriptor tables remain shared after exec(), ditto for
> > cwd/root/umask...
>
> POSIX says nothing, as far as I can tell, about the effect of exec on
> threads. However, it does say pending signals must be inherited. It's
> unclear what should happen in Linux, but it might be good for the new
> process to still be a thread in the thread group -- although it won't
> be sharing memory anymore.
That's a terrible plan. Imagine a MT server app doing signal-based
async I/O. Now one of the threads exec's something... under this plan
the new unrelated thread will get some percentage of the signals. And
what happens if the new process is MT - all the threads from both
processes are in the same group?!?
The whole point of inheriting pending signals is that the old process
doesn't exist any more so it won't handle the signals. If the signal
was sent to a MT app this isn't the case - the other threads will still
be around to get that signal.
I should point out that my kernel-thread suggestion gets this case
99% correct automatically. Signals that were sent directly to a
slave thread's pid will get inherited, ones sent to the thread group
as a whole will still be in the master thread and thus stay put.
The two things I see that are still a little wierd with MT execve under
my scheme:
* Since the exec will start a new thread-group-leader (i.e. a pid
which is the sole thread in a new process) getpid() will return
a different value than just before the execve() (since we've
replaced the pid of a slave thread, not the master). I don't
see any sane way of rectifying this. But hey, MT execve is
undefined anyway, so a little weirness is to be expected.
* What happens if the last thread in a MT app execve's? In this case
the pending signals probably need to be inherited. This is an
important case since the program might have been MT for awhile
to do some big calculation and has now collapsed to a single thread
again. This probably just needs to be a specail case in sys_execve:
"if we're the last thread in an MT program, throw away this thread
and make it look like the master thread had performed the exec"
This solves the signal inheritance and the getpid issue in this
case.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST