RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

["Robert White" <rwhite@casabyte.com>]

I can say that (virtually) any programmer who does a lot of threads work is
going to presume that he may pass file handles between threads safely.

IMHO it would be exceptionally bad to break this assumption.

At the purist level, when I pass an abstraction (data structure etc) around
between my threads, having done my due-diligence WRT locking and such, I
expect that when the abstraction gets there it will still be valid.

Consider:

class ObjectList { /* whatever */ };

class CachedObjectList: public ObjectList {
    iostream	SlowStorage;
    /* whatever */
};

/* global, locks not shown */ vector<ObjectList*> central_registry;

One would *expect* that one could add CachedObjectList objects to the
central registry and then use them in any thread as long as access/locking
paradigms were strictly followed.

If every thread *doesn't* have the exact same set of files open in exactly
the same handles, this would not be true.

I would go as far as saying that if CLONE_THREAD *MUST* imply CLONE_FILES
automatically or Very Bad Things(tm) could happen.

For instance, if two threads have opened different files as fd==10, when the
shared data structure above passed from one thread to the other (with
SlowStorage attached to fd 10), the buffered output from the first task
could get flushed into the file opened by the second thread at whatever its
write pointer happens to be set to.  Etc.

Rob. 


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Albert Cahalan
Sent: Thursday, October 02, 2003 5:03 PM
To: Ulrich Drepper
Cc: Albert Cahalan; Linus Torvalds; Mikael Pettersson; Kernel Mailing List
Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?


No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.
Remember, the last stable release of the kernel (2.4.xx)
didn't have the ability to do CLONE_THREAD at all. So it
isn't as if real-world apps are depending on the ability
to do CLONE_THREAD w/o sharing file descriptors.