Web Locks API

[benjamingr]

Chrome 70 ships with Web Locks:

The Web Locks API allows scripts running in one tab or worker to asynchronously acquire a lock, hold it while work is performed, then release it. While held, no other script executing in the same origin can acquire the same lock, which allows a web app running in multiple tabs or workers to coordinate work and the use of resources.

navigator.locks.request('my_resource', async lock => {
   // The lock has been acquired.
   await do_something();
   await do_something_else();
   // Now the lock will be released.
});

Would it make sense for Node to ship such an API for workers (or even child processes)?

cc @nodejs/workers @nodejs/open-standards

[addaleax]

Would it make sense for Node to ship such an API for workers (or even child processes)?

I think so, yes. I think an implementation that supports child processes would be significantly different (and harder to do), so if we want to support that, it might help if we decided that upfront.

[benjamingr]

I think these sort of locks would make a much nicer API than Atomics.wait for synchronizing threads + I like the fact it's using a disposer.

Some things to note:

• It uses AbortSignal which we currently don't have, arguably we should for other things too
• The resource name is a string which I'm not a huge fan of since it means threaded code can accidentally interfere with other threaded code - would be great if it took a symbol or an object.

cc @inexorabletash @annevk @jakearchibald (if any of you don't like pings let me know and I won't in the future) - would just really appreciate some feedback from people involved.

[cjihrig]

I think an implementation that supports child processes would be significantly different

I've done some work on a cross process semaphore that might be applicable (no Windows support).

https://www.npmjs.com/package/semafour

[targos]

The resource name is a string which I'm not a huge fan of since it means threaded code can accidentally interfere with other threaded code - would be great if it took a symbol or an object.

I don't see how it could be possible. There is no way to have two reference-equal objects between two workers and the only way to do it with a symbol is to do Symbol.for(name), which is basically the same as using a string.

[benjamingr]

I don't see how it could be possible. There is no way to have two reference-equal objects between two workers and the only way to do it with a symbol is to do Symbol.for(name), which is basically the same as using a string.

Hmm, for example:

• Open a MessagePort
• Pass a SharedArrayBuffer over that MessagePort
• Lock on the SharedArrayBuffer

Similarly, if symbols could be passed to workers and stay equal that would also work.

I totally get the point though.

[mcollina]

I am conflicted about this API. One of the greatest feature of Node.js is that it is really hard to create a deadlock. I'm not sure if making it easy is something that we should really look for. In the context of servers, this is extremely powerful and extremely dangerous at the same time. A browser user can always refresh a tab, the 1000s of users of a server can all get stuck.

I would like to ask some questions:

1. can this feature be implemented in the ecosystem?
2. is there significant Browser usage to consider it before adding?
3. has it been required by our community in any form?
4. is this needed to provide a good API for workers?
5. what happens if we try to acquire the same lock in two different places within the same thread?

The implementation for this should be extremely easy to debug, I think it should also have some safety measures in place to detect deadlock situations and crash the process.

For diagnostics purposes, it should have at least async_hooks support, and possibly trace events too.

I'm -1 on having this for child processes or cluster. Supporting that cross-platform would be very complicated.

+1 for workers, as long as the implementation does not pollute global scope in any form.

[bmeck]

If there are concerns with a locking API using Strings, and with it using Objects. Why not allow both?

// Assume it would try to lock only first index???
locks.requestFromSharedArrayBuffer(SharedArrayBuffer, ...);
locks.request(string, ...);

[devsnek]

I'd be interested in taking this up

[jasnell]

can this feature be implemented in the ecosystem?

With a native addon, yes. Tho I'm not certain that a native addon would cover everything. It should be explored.

is there significant Browser usage to consider it before adding?

No. Chrome and Opera are the only implementing browsers so far.

has it been required by our community in any form?

Unclear.

is this needed to provide a good API for workers?

I believe it will be. Whether this specific API or not, locks will at some point be necessary.

what happens if we try to acquire the same lock in two different places within the same thread?

That's unclear.

I'd like to see more experimentation with this before it lands.

[addaleax]

is this needed to provide a good API for workers?

I believe it will be. Whether this specific API or not, locks will at some point be necessary.

I agree. And while we do have Atomics available, this API will provide a much better user experience out-of-the-box.

[targos]

what happens if we try to acquire the same lock in two different places within the same thread?

In Chrome, it seems to have a queue and execute them in the order they were requested:

function wait(s) { return new Promise((res) => setTimeout(res, s*1000)); }
navigator.locks.request('test', async () => {
    console.log('before 1');
	await wait(1);
	console.log('after 1');
});
navigator.locks.request('test', async () => {
    console.log('before 2');
	await wait(1);
	console.log('after 2');
});

Output:

before 1
after 1
before 2
after 2

[inexorabletash]

Hey folks - happy to answer questions. In case you haven't found it, there's an early spec and the repo is at https://github.com/WICG/web-locks which has issues tracking the history and decisions, and also some proposed next steps for the API.

what happens if we try to acquire the same lock in two different places within the same thread

As @targos mentions, it would be blocked; this is covered in the explainer (see "If a tab is holding an exclusive lock, what happens if another lock request for the same resource is made?") but I don't think that's reflected explicitly in the spec.

[GrosSacASac]

Can someone clarify the differences with Atomics ? Does anyone use Atomics ?