Yes, that's when you view it as a locking problem, as for data
objects. What I'm saying is that, if you manage the data
structures properly, plus fix a few interfaces that currently
don't have to manage data structures properly, you're already
perfectly synchronized, so no further locking is needed.
> I assume you're referring to the many places where we assume that the
> structure being added was not dynamically allocated, so don't bother
> to protect against its deletion?
Yes.
> And in general, I agree: not including a refcount is asking for
> trouble. But these reference counts are *not* free.
Alas, no. But we how long can we afford not to fix them, at least
the "public" interfaces ? Even if they're unsafe, people will use
them, particularly if they're given no other choice.
> object separately from any objects it might create. The current
> implementation is extremely fast, requires neither module changes nor
> (many) interface changes, and in effect canonicalizes a single
> existing method of locking, which coders seem quite comfortable with.
It's more the changes behind the interfaces I'm worried about.
It may not be bad today, but every function pointer is a
potential problem.
Anyway, without fixing a good number of the "ghost from the
past" interfaces first, my point is moot. So I won't trouble
you again with module locking before there is some progress in
this area :-)
> Given these reasons, you can see why I no longer discuss new
> implementation ideas with people 8(
Nah, don't give up ! :-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/