Messages in this thread | | | Subject | Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? | From | Albert Cahalan <> | Date | 02 Oct 2003 09:48:59 -0400 |
| |
On Thu, 2003-10-02 at 00:58, Ulrich Drepper wrote: > Albert Cahalan wrote: > > > In that case, don't you already have a severe mess? > > [...] > > That's all completely up to whoever decides to use this combination of > CLONE_* flags. It might mean that SIGIO cannot be used and that fuser > cannot be used. But so what? That might be acceptable in that > situation.
To the user, maybe. To the admin, no. The admin uses fuser and/or lsof to find out why he can't umount. If those programs were thread-aware (they are not), then they could take many minutes to run.
In other words, stuff runs faster if we can ban this. If not, please suggest a way to make fuser and lsof fast.
> Of course it could be redefined as "point to the process group leader" > but I'm not sure whether this and introducing "/proc/task" or so is > worth the trouble.
Adding a /proc/task isn't any more trouble. I guess I'll do that in any case.
If /proc/self should be some deprecated hack that goes through the invisible non-leader directories at top-level, then it itself should be made invisible and a /proc/proc (pointing to tgid) should be added. A /proc/proc could be backported to 2.4.xx. We'd then have top-level links for process (tgid, "proc", POSIX PID), thread (pid, "task", POSIX TID), and... an ugly thing that we can kill 5 years from now.
- 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/
| |