On Fri, 21 Apr 2000, Manfred Spraul wrote:
> kumon@flab.fujitsu.co.jp wrote:
> >
> > But I don't realy understand, what portion actually needs the lock?
>
> Only the innermost "->poll()" call needs the lock.
Actually, that is something we might change right now - the read() and
write() downcalls are already done without the kernel lock, and poll() is
actually much easier than either of those - I suspect that pretty much
every poll() function is already SMP-safe. The networking versions of
poll() in fact drop the lock explicitly, and those are just about the most
complex poll() implementations anywhere.
So the right solution may in fact be to remove the kernel lock altogether,
and also make sure that the networking code stops playing with it for
their poll() implementation. I doubt you'll find anything that breaks,
simply because the way poll() is done under Linux is rather thread-safe
(ie the double-calling on failure gets rid of all the hard races). And
most poll() implementations just check a flag and add themselves to the
wait queues, all of which is perfectly SMP-safe already.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:19 EST