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

[bill davidsen]

In article <Pine.LNX.4.44.0310021720510.7833-100000@xxxxxxxxxxxxx>,
Linus Torvalds  <torvalds@xxxxxxxx> wrote:
| 
| On 2 Oct 2003, Albert Cahalan wrote:
| > 
| > No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.
| 
| No. Let's not do that.
| 
| We ban only things that do not make sense. That was true of trying to 
| share signal handlers with different address spaces. But it is _not_ true 
| of having separate file descriptors for different threads.
| 
| I don't imagine anybody cares _that_ deeply about fuser that it can't 
| afford to recurse into thread directories.
| 
| And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
| directory at all if the thread shares file descriptors with the thread 
| group leader. That would be a fairly easy optimization.

I think Albert has a good point on performance, since nothing is using
the ability to have separate fd sets, I can't see it as a requirement.
However, I have an application which has a lot of files and sockets
open, and I think having the separation may make things far nicer when
not all the threads need have everything open.

But if there are going to be both kinds of threaded processes, there
should be a good way to tell if a program like lsof needs to chase every
thread or not. I'm not totally sure what Albert has in mind for
/proc/task, but if there were a way to create subdirs only for threads
with separate fd space, that would be one approach.

lsof is painful now, hopefully for things which share fd it can be much
faster.

And how does this new capability fit with SUS, if at all?
-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/