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

From: Alexander Viro (viro@math.psu.edu)
Date: Sun Aug 27 2000 - 22:30:55 EST


On Sun, 27 Aug 2000, Linus Torvalds wrote:

> I really think that we should have added a "break these connections"
> mask to execve(), so that the user woul dget full control - and then we
> could truly export the sensible Linux "execve from thread" semantics as
> a POSIX extension to pthreads.

Linus, there is no need in new mask for execve(). We have two actions:
        1. create a VM set up according to the contents of binary
        2. create a private copies of some previosuly shared components
Notice that there is no need to combine them in one - if you want
exec-with-private-files you can make your files private and then call
execve(). And you may very well want to get the private copies of
files/signal handlers/etc. without doing exec(). We even have a natural
API for that.

Just look what clone() does: it takes the components of the caller (thread
of execution + VM + descriptors + signals +...), creates copies of some of
them (those that are not in the bitmap we've passed) and combines the
results (private copies of what we've copied + old instances of the rest)
into the process. Right?

        Now, notice that we _always_ copy the thread of execution (aka.
task_struct). What if we allow to take the old one? After all, we can do
it with everything else. Well, then we create copies of some components
and combine them with the old instances of the rest. Including the old
task_struct. I.e. we replace some of the ->files, ->fs, ->mm, etc. with
the private copies, leave the rest untouched and drop the references to
the stuff we've replaced with copies. But that's precisely this "unshare"
operation, complete with the bitmap.

        IOW, unshare(bitmap) is precisely what clone(CLONE_TASK|bitmap)
would be. And it both provides an easy way to get your execve_unshare()
and makes sense on its own. E.g. thread may decide that from now on it
will not share descriptors with anybody else, etc.

-
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