Messages in this thread | | | From | "Robert White" <> | Subject | RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? | Date | Wed, 8 Oct 2003 14:54:02 -0700 |
| |
Actually, the pthread library is at a higher level than the clone() system call (where I was phrasing my debate.)
That library already does "the right thing" by requesting that the file descriptors be shared explicitly. It must for the pthread paradigm to work. Therefore it presumably still will.
That is libpthread "does" and "should" make the requests for new OS threads with the unified file descriptor table case. So the below will keep working as expected.
I was barking up a different tree with my arguments. (e.g. what is the minimal definition of thread in the mind of the kernel.)
So unless the pthread implementer makes a mistake, the POSIX level of abstraction will be right regardless.
Rob.
-----Original Message----- From: bert hubert [mailto:ahu@ds9a.nl] Sent: Wednesday, October 08, 2003 3:47 AM To: Linus Torvalds Cc: Robert White; 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson'; 'Kernel Mailing List' Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
On Tue, Oct 07, 2003 at 05:54:35PM -0700, Linus Torvalds wrote:
> But the same isn't true of file descriptors or a lot of other software- > level abstractions. There are no inherent advantages to sharing, and in > fact sharing just gives more opportunity for race conditions, bad > interaction etc.
I may be missing something, I'm all for the ability to have threads with their own fd namespace, but will NPTL/Linux retain the capability to pass fd's to other threads?
One thing I've used in tens of programs is:
void *session(void *p) { int fd=(int)p; ... } ...
for(;;) { fd=accept(); pthread_create_thread(session,(void*)fd); }
I'd like to continue to have that ability.
Thanks.
-- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
- 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/
| |