Messages in this thread | | | Date | Sat, 11 Oct 2003 04:48:20 +0100 | From | viro@parcelfa ... | Subject | Re: Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES |
| |
On Fri, Oct 10, 2003 at 08:02:49PM -0700, Robert White wrote: > For those who care: > > Earlier I was phrasing arguments for requiring that the CLONE_THREAD > argument to clone() require implication of CLONE_FILES. I officially recant > those arguments. In those prior posts I asked for a specific demonstrable > case against this requirement. Having found one myself, I provide it here > so that if the question comes up again from other quarters it can be > answered (or killed 8-) more easily. > > [This post is significantly aimed at persons searching the mailing list so > please forgive some of the more elementary observations. Near the end I do > a compare and contrast of the kernel provided clone() feature to the pthread > and java task paradigms for those who got here via the words "thread" or > "task".]
[snip]
One note: non-shared descriptor table with shared VM (or vice versa) is not unique to Linux. *BSD have a syscall very similar in spirit to clone(2) - rfork(2). So does Plan 9, where that beast had originated.
IOW, that model is actually *absent* only in SysV - arguably, the least Unix-like of Unix clones...
{Free,Open,Net}BSD rfork() differs from clone() only in arguments. Plan 9 one always gives task-private stack - even if VM is otherwise shared.
BTW, there's a bunch of syscalls that require careful userland code if descriptors _are_ shared - select() is a good example, since we get the answer in terms of descriptor table at the moment of call. Having one thread put descriptor 42 into set, call select and return after another thread does close(42); or dup2(fd, 42)... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |