Messages in this thread |  | | Date | Sun, 27 Aug 2000 23:30:55 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on |
| |
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/
|  |