Re: Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES

[viro@parcelfarce.linux.theplanet.co.uk]

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)...