On Sun, Aug 27, 2000 at 10:59:17AM -0400, Horst von Brand wrote:
> Mitchell Blank Jr <mitch@sfgoth.com> 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 vonbrand@sleipnir.valparaiso.cl
> Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- 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:20 EST