Skip to content
This repository has been archived by the owner on Mar 5, 2021. It is now read-only.

Implement a resource locking system to protect against race conditions #67

Open
elisee opened this issue Jan 17, 2016 · 1 comment
Open

Comments

@elisee
Copy link
Contributor

elisee commented Jan 17, 2016

If an asset takes a while to be written to disk or is written to disk in several steps, it could be deleted while in middle of saving. Other similar non-atomic operations involving async callbacks might clash and lead to crashes. This is a theoretical issue at this point, but something we should tackle before it bites us.

The best approach is to create a type of asset that takes 5s+ to write itself to disk (by adding a setTimeout between steps) and then provoking a bug by doing a conflicting action while that is happening.

Then we can fix it properly by having global locks that must be acquired before a long-running operation can start.

npm modules to look into: https://www.npmjs.com/package/async-lock and https://www.npmjs.com/package/rwlock.

@elisee elisee changed the title Add a lock system for actions that shouldn't happen concurrently. Implement a resource locking system to protect against race conditions Jan 17, 2016
@elisee
Copy link
Contributor Author

elisee commented Mar 16, 2016

Just landed the locking mechanism (went with async-lock) and its first use to protect from race conditions in BaseRemoteClient.sub and .unsub.

This fixes an actual bug where the server would think we were still subscribed to an asset if we subscribed and then unsubscribed before it was done loading the asset from disk, so we know it works and it's useful.

Now we just need to figure out all the places where we should use this :D

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant