Auto-release locks after a configurable amount of time has elapsed

[vaidik]

This can help with preventing locks that are never released due to unhandled errors or in some cases where network calls take excessively long to complete

[ronkorving]

I would very much like the scope of locks to remain small. I'm wondering if there would be enough interest in this feature, and if it's not easy enough to do in userland. Perhaps you can elaborate on any pains you may experience by doing this userland?

[XeniaSiskaki]

I'm not sure about auto-releasing but there is definitely the need to allow the user to manually release all locks.

Consider my scenario: I have an API server (written in nodejs/express). A specific API request is dealing with multiple RxJS streams, each of which at some point requests a lock to do some processing. In case there is an error in any of the streams, the server will just send a status 500 error to the client. In this case, if I just release the last lock, won't the lock continue to be given to the rest of the queued callbacks, which will lead to more errors?

Please correct me if I'm wrong in my assumption.

[ronkorving]

@XeniaSiskaki That sounds reasonable, and should be easy to add. Something like Mutex.prototype.reset() that just forgets about all waiting callbacks? So you first reset, then unlock, and all is well. Of course you will want to stop new requests from queuing up again, but I think that's a userland concern.

[XeniaSiskaki]

Something like this, yes! Or if you don't want to introduce a new function, I just use unlock with an all flag (see https://github.com/XeniaSiskaki/locks/blob/master/lib/Mutex.js#L63-L80)

I can issue a PR if you want

[ronkorving]

@XeniaSiskaki PR very welcome! If you're okay, I think I prefer a separate function. Thanks!