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

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

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