Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 | Date | Sun, 27 Aug 2000 23:02:12 +0400 (MSK DST) |
| |
Hello!
> > It is nonportable _only_ to Linux (and to old freebsds btw, > > its user level pthread library had the same bug). > > Huh?
Al, I specially wrote "old" freebsd, because I do not know anything about new ones. At least, FreeBSD folks promised to fix this, when they will implement their own linux-like threads. I even do not know, did they imlemented them eventually or they did not. 8)
Their user-level thread library is surely buggy and this is not the only bug there.
> And *BSD, unless they are using some userland wrappers around the read(2). > Which may be the case, but then I don't see where it becomes a kernel > problem on our end of things.
When kernel leaves process frozen, the bug is in kernel.
Did process close file? Yes. Does user have some references to this file to control it? No! P...ts. All the arguments sort of "user is fool" are pure demagogy. This thing is called "leakage" usually and for user level it looks exactly as leakage. Kernel is not self-consistent. Period.
If you are still in doubts, look at analogies in FS. You make "ls somedir" in one shell continuosuly. You make "rmdir somedir; mkdir somedir" in another one. You get lots of errors "No such directory", but processes do not hang and unlinked but "still referenced by ls" directories do not overflow file tables. User is surely makes some crap, but it is his right 8).
Another analogy, look at mm_struct. It has mm_users and mm_count. Why? Following situation with files, mm_count is enough. And bug poor users, when mm is not cleared occasionally.
You can find the same logic in any object maintanance system.
Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |