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

Robert White
2003-10-08T03:00:13Z

Actually, the point I am trying to _make_ is that Linux allows you to share
or not share each item (already) but making a coherent "thread" implies a
unity of interface over the entities. We already have VM and Signals in
that unity, but not file descriptors. I think that's bad. Since the old
way lets me have this 2/3-of-a-thread already. When I ask for a thread I
should get a thread, not just a composite of otherwise identical shareable
options.

After all, if I deliver SIGPIPE to a "process" and it gets serviced by one
of the "theads" how does the "thread" know the file descriptor in the signal
is from its own file descriptor table? If the signals are only going to the
specific member threads and, in fact NOT to the "process", then how is the
sharing of signal context anything more than a renaming of what is already
there as of 2.2?

If CLONE_THREAD exists solely to reproduce the existing
(CLONE_VM|CLONE_SIGHAND[|CLONE_whatever]) functionality, why did anybody
bother doing more than a #define?

Presumably CLONE_THREAD is supposed to make a LWP (in the classic sense)
that runs with view of the kernel that is consistent with all its peer LWPs.
If not, it is going to surprise a heck of a lot of (posix AND non posix)
thread programmers worldwide. "They ought to know better" has merit, but
that merit is equal to "they might as well use the old stuff".

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of David Lang
Sent: Tuesday, October 07, 2003 7:39 PM
To: Robert White
Cc: 'Linus Torvalds'; 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael
Pettersson'; 'Kernel Mailing List'
Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

Robert, you are missing the point. Linux allows you to share or not share
each item.
.