Nikodemus Siivola <nikodemus@...> writes:
> On 26 March 2010 01:23, Tobias C. Rittweiler <tcr@...> wrote:
>> Apropos GET-MUTEX; that takes two &optionals now. GET-MUTEX is an
>> exported function from a public package -- does that mean that it's API
>> must be considered frozen? I.e. can I change &optional to &key?
>> In case the answer to the last question is "no", I suggest to deprecate
>> GET-MUTEX, and introduce a function GRAB-MUTEX instead which takes &key.
> I've been thinking about our locking API for a while now. I think it
> is wrong in several ways. Basically, I would like to introduce an
> alternative API that makes it all better.
> Something like:
> function MAKE-LOCK &key name recursive depends-on
> RECURSIVE allows recursive GRAB-LOCK.
> DEPENDS-ON can be used to specify another lock that must be held prior
> to grabbing this one.
> (Maybe also :CHECK-DEADLOCKS or :DEBUG to specify that we should
> check for deadlocks
> before going to sleep on the lock.)
> function GRAB-LOCK lock &key timeout
> function TRY-LOCK lock
> function RELEASE-LOCK lock &key if-not-owner
> function LOCK-NAME lock
> function LOCK-DEPENDS-ON lock
> function LOCK-OWNER lock
> function LOCK-HELD-P lock
> macro WITH-LOCK (lock &key timeout) &body body
> ...but that's just me. I'm not strictly against trying to rejigger the
> current API, but I think deprecating it and replacing it with another
> would be better in the long term.
It -may- make sense to allow subclassing LOCK (structures-are-classes,
where are thou?), and make the expansion of WITH-LOCK to a
CALL-WITH-LOCK function call explicit.
I often see WITH-FOO-LOCKED macros which could be written by an :AROUND
method on CALL-WITH-LOCK on a FOO-LOCK class. Doing it that way purports
to (perhaps arguably!) be TRT.