Re: Patch for fields of `struct buffer'

[Tom Tromey]

>>>>> "Daniel" == Daniel Colascione <address@hidden> writes:

Tom> Instead of explicit locks, just let any symbol function as a lock, and
Tom> have the locks hidden in the C code.

Daniel> While elegant, I'm afraid using symbols as locks would lead to a
Daniel> proliferation of locks of code, not data. Using a symbol as a big global
Daniel> lock is easier than using gensym to get per-object locks.

I don't really understand this.  I think it doesn't matter, though,
since after thinking about it some more, I think that it at least makes
sense to want to lock buffers.

Tom> (Or an extension of this idea, let
Tom> any Lisp object be a lock -- "Java style".)

Daniel> This approach has potential. I believe JVMs get away with this trick at
Daniel> a cost of a machine word per object --- that's a big addition to a
Daniel> simple cons cell, of which Emacs has quite a few.

Modern JVMs don't pay anywhere near this price.  JVM developers noticed
a long time ago that most object's locks are never acquired, and that
those that are acquired are usually uncontended, and optimized their
implementations accordingly.

If we went the "lock anything" route, I would suggest a weak hash table
for locks, instead of putting the lock into the object.

Tom