Messages in this thread | | | From | "Robert White" <> | Subject | RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? | Date | Tue, 7 Oct 2003 19:59:18 -0700 |
| |
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. .
- 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/
| |