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

From: Mark Kettenis (
Date: Sun Aug 27 2000 - 07:39:09 EST

   Date: Sun, 27 Aug 2000 05:12:41 -0600
   Cc: Alan Cox <>, Andi Kleen <>,
      Linus Torvalds <>, Alon Ziv <>,
      Mark Kettenis <>,
   Content-Type: text/plain; charset=us-ascii

   On Thu, Aug 24, 2000 at 05:31:04PM -0400, Alexander Viro wrote:
> On Thu, 24 Aug 2000, Alan Cox wrote:
> > same thread group - the original I believe didnt. So long as that is
> > done right and your thread group changes on an exec (obviously) then I
> 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.

The current draft for IEEE Std. 1003.1-200x says:

"A call to any exec function from a process with more than one thread
 results in all threads being terminated and the new executable image
 being loaded and executed. No destructor functions shall be called."

This doesn't necessariliy mean that the kernel should enforce this,
but it should be possible to have an exec in any thread in a thread
group and end up with a single thread executing the new process image,
with the same POSIX process id as before the exec. So I'm afraid the
"thread group change on exec" assumption of Alan isn't obvious :-(.

By the way, it looks like the behaviour of exec with respect to
signals is ill-specified. The specification says that the "process
signal mask" is inherited by the new process. Is that the signal mask
of the calling thread, the signal mask of the initial thread, or some
sort of process wide mask (which doesn't have to exist). The same
holds for the the pending signals. Pending for the process, for the
calling thread or perhaps a union of both?

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