search

w3c / web-locks

Cross-tab resource coordination API
https://w3c.github.io/web-locks/
Other
124 stars 16 forks source link

Avoid deadlocks entirely via crafty API design? #28

Closed inexorabletash closed 6 years ago

inexorabletash commented 6 years ago

From offline conversation with @slightlyoff:

If acquisition of multiple locks was enforced via strict ordering at the context level it would be possible to avoid deadlocks.

For example, define a lock stack for each context and a strict ordering (e.g. lexicographical string collation). When a lock is requested, push the name on the stack. When it is released/aborted, pop the name from the stack. If a lock is requested and the stack would not be well ordered, reject the request.

How feasible would this restriction be to impose now?

ralphch0 commented 6 years ago

What's does "context" refer to here? Is it "a web page" or the whole chrome profile?

inexorabletash commented 6 years ago

Frame/worker ("agent").

pwnall commented 6 years ago

This would break libraries' abilities to use namespaces for independent functionality. 'google:' locks would have to be acquired before 'twitter:' locks.

It might be tempting to introduce official namespaces and make the spec namespace-aware, but then you'd be exposing the problem back to the user. For example, if a library holds a lock during an async callback, the user code in the callback can invoke another library.

And for a database analogy: SQL databases have to handle deadlocks because they must accept arbitrary queries and updates in transactions. IndexedDB side-stepped deadlocks nicely with its transaction scopes, at the cost of potential false conflicts.

inexorabletash commented 6 years ago

This doesn't seem possible with significantly compromising the utility as a primitive.