lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.169 / U:13.512 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site