Wietse Venema wrote: > Howard Chu: >> The first patch adds a lock handler to the dict interface. I needed this >> first, because MDB is fully transactional and does its own >> locking/concurrency >> management. In particular, it does MVCC so readers always run lockless; since >> they're fully isolated there's no actual need for "shared locks." > > That change is unnecessary. All you need is a way to tell the caller > that it must not perform explicit lock management. > > You can satisfy that need that without damage to existing code, > simply by introducing a new flag that the caller can test.
Such a change strikes me as being a greater code maintenance burden in the future, as every caller to the dict functions must check your proposed flag explicitly. As you said in your previous reply, one size does not fit all. But your existing code assumes that there is only one type of locking for all dict types. It doesn't make sense for code like tls/tls_scache.c to assume that just because dict->lock_fd hasn't been set, that no form of locking is supported. Indeed, exposing internal details of how a dict module handles locks to its callers is more of an abstraction layer violation than a feature. > I already have flags with which a map can announce its properties. > For example, if the map can be used for security-sensitive data, > or if it matches the lookup keys against fixed strings or against > patterns. > > You're welcome to add another flag that says "I can take care of > locks if I need to, thank you very much". I can certainly do this if that's really the way you want to go. But I'd ask you to reconsider... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
