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

Date: Sun Aug 27 2000 - 18:54:49 EST

On Sun, Aug 27, 2000 at 10:59:17AM -0400, Horst von Brand wrote:
> Mitchell Blank Jr <> said:
> [...]
> > It would make the most sense for it to just surplant the thread that
> > called it, I think. I don't see what the value of having all the
> > other theads asyncronously disappear is.
> Threads aren't processes, they share VM. To exec ls(1) sharing VM with a
> bunch of threads?! What if the process launched is itself multithreaded,
> what relationship will there be among the child's threads and the parent's?

In Linux, currently, threads are processes.

> IMVHO, your suggestion makes sense for fork(2) from a thread, while exec(2)
> there doesn't make much sense at all.

In the POSIX spec fork demolishes all threads in the child. This is the
only sensible answer and it seems wasteful to ignore the rare sensible
parts of the POSIX spec. I think exec should do the same thing: calling
thread should die and be replaced by a thread/process that is not in the
thread group since it no longer shares memory.

> --
> Horst von Brand
> Casilla 9G, Vin~a del Mar, Chile +56 32 672616

Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.

- 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:20 EST