Messages in this thread | | | Date | Sun, 21 Dec 2003 14:05:08 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [RFC,PATCH] use rcu for fasync_lock |
| |
On Sun, 21 Dec 2003, Manfred Spraul wrote: > > >Here's a big clue: if you make code worse than it is today, it won't be > >accepted. I don't even see why you'd bother in the first place. > > fasync_helper != kill_fasync > fasync_helper is rare, and usually running under lock_kernel().
But we want to get rid of lock_kernel(), not create new code that depends on it.
And _especially_ if fasync_helper() is rarely used, that means that changing the callers to have a nicer calling convention would not be painful.
> kill_fasync is far more common (every pipe_read and _write), I want to > remove the unconditional read_lock(&global_lock).
Note that my personal preference would be to kill off "kill_fasync()" entirely.
We actually have almost all the infrastructure in place already: it's called a "wait queue". In 2.5.x it took a callback function, and the only thing missing is really the "band" information at wakeup time.
So if we instead made the whole fasync infrastructure use the existing wait-queues, and made wakeup() say what kind of wakeup it is, we could probably get rid of the specific fasync datastructures entirely. And we'd only take locks that we take _anyway_.
I dunno. But to me that at least sounds like a real cleanup.
> Today's solution is two copies of fasync_helper: one with lock_sock in > net/socket.c, one with write_lock_irq(&fasync_lock) in fs/fcntl.c.
And two functions that statically do something different is actually _better_ than one function that does two different things dynamically.
And if the two cases have different locking, then they should remain as two separate cases.
Linus - 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/
| |