Re: SCO: "thread creation is about a thousand times faster than on

From: Mitchell Blank Jr (
Date: Sun Aug 27 2000 - 08:01:14 EST 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST