Open bakkot opened 1 week ago
I'd kind of expect the mutex to be locked after a call to mutex.lock(...), which it isn't.
In case of timeout, you mean? I got confused with what version you're referring to. I think you're referring to the callback-taking version instead of a simple lock/unlock version, or one with a disposable token as you've proposed.
Sorry, yes, referring to the callback-taking version in the readme:
mutex.lock(function runsUnderLock() {
// Do critical section stuff
});
.lock()
is a perfectly reasonable name for the simple lock/unlock version or the one taking a token, but I don't think it makes sense as a name for "run this function after acquiring the lock, then release the lock".
I'm writing the spec draft right now and sorely need to update the README, but I'm moving away from the callback taking version to start in favor of either the simple lock/unlock for flexibility in the future with dispose, or the token. I need to noodle on the token thing some more, will reply in the other thread.
Swift calls these
withLock
andwithLockIfAvailable
, which I think are better names.I'd kind of expect the mutex to be locked after a call to
mutex.lock(...)
, which it isn't.And
try
in JS usually means something to do with exceptions; it's a bit weird to see it used in another context.