locking dictionaries (was Re: New statement proposal for Python)
Tim Peters
tim.one at home.com
Wed Jun 20 22:04:15 EDT 2001
[Aahz]
> OTOH, there's been some discussion of locking dicts during certain
> operations to prevent some ugly bugs and crashes.
[Greg Ewing]
> I'm given to understand that, in the case of lists, this is achieved
> by temporarily changing the type pointer. If a similar thing were done
> for dicts, presumably it wouldn't have any effect on the performance of
> non-locked dicts.
No rational effect, anyway. For example, if you wanted a dict that refused
to delete items, give it a type object almost exactly like a regular dict's,
except redirect its tp_as_mapping slot to a PyMappingMethods struct with a
custom mp_ass_subscript slot (that makes more sense if you look at the code
<wink -- but this is just CPython's current way of faking inheritance in C,
at the level of hand-coded vtables>). They can share the rest of the dict
implementation, and modulo "cache effects" this should have no effect at all
on regular dict speed.
But note that there's really no way to do this without editing dictobject.c:
unlike *most* of the Python types, the representation of dicts can't be
gotten from an #include file. They're one of Python's few true "black box"
types at the C level, and that's deliberate (the internal representation of
dicts has changed frequently, and has changed again for 2.2 -- but since it
was never available outside dictobject.c, nothing will break).
More information about the Python-list
mailing list