Repository navigation
Web Locks API #22702
Description
Activity
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.
Reacted by Sagir Khan, Benjamin Gruenbaum, Denys Otrishko, Linz, Andrej Kirejeŭ and Tierney CyrenI think these sort of locks would make a much nicer API than
Atomics.waitfor synchronizing threads + I like the fact it's using a disposer.Some things to note:
- It uses
AbortSignalwhich 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.
Reacted by Denys Otrishko and Andrej Kirejeŭ- It uses
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).
Reacted by Benjamin GruenbaumThe 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.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.
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:
- can this feature be implemented in the ecosystem?
- is there significant Browser usage to consider it before adding?
- has it been required by our community in any form?
- is this needed to provide a good API for workers?
- 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.
Reacted by Anna Henningsen, Benjamin Gruenbaum, GP, Michael Dawson and Sasha RudanIf 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, ...);
I'd be interested in taking this up
Reacted by Benjamin Gruenbaum, Matteo Collina, Victor Costan and krirccReacted by Benjamin Gruenbaum, Nikita Skovoroda, Victor Costan, krircc and Alex Yangcan 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.
Reacted by Anna Henningsen, Matteo Collina and Sergey Rubanovis 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
Atomicsavailable, this API will provide a much better user experience out-of-the-box.Reacted by Matteo Collina, Benjamin Gruenbaum and Sergey Rubanovwhat 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 2Hey 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.
Reacted by Benjamin Gruenbaum, GP, Victor Costan and junerCan someone clarify the differences with Atomics ? Does anyone use Atomics ?
29 remaining items
Please keep this open.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
@sindresorhus I'm thinking we might mark this never stale, but I think it would be good if you added a bit of context since you asked we keep it open. Just wondering if its because as a Web API we still want to consider adding it or if there is more than that and somebody is working on it?
It might be a good idea to bring this up in WinterCG and if there is interest to standardize this (on the server) and implement it.
Reacted by Tierney CyrenThere has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
This was released in v24 #58666
Reacted by Anton Bessonov
Chrome 70 ships with Web Locks:
Would it make sense for Node to ship such an API for workers (or even child processes)?
cc @nodejs/workers @nodejs/open-standards