Messages in this thread |  | | Date | Sun, 27 Aug 2000 14:39:09 +0200 | From | Mark Kettenis <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on |
| |
Date: Sun, 27 Aug 2000 05:12:41 -0600 From: yodaiken@fsmlabs.com Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Andi Kleen <ak@suse.de>, Linus Torvalds <torvalds@transmeta.com>, Alon Ziv <alonz@usa.net>, Mark Kettenis <kettenis@wins.uva.nl>, linux-kernel@vger.kernel.org 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?
Mark - 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/
|  |