-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding a locking test case #99
Conversation
I haven't run this test but from what I can see this passes because I think you might be able to create a deadlock by trying to acquire a write lock during a read lock: // getMany opens a (shared) read lock
for await (const block of helia.blockstore.getMany(someAsyncCIDEmitter)) {
// gc opens a (exclusive) write lock, but needs to wait for the read lock to be released
await helia.gc()
} To break the deadlock there should be some sort of timeout mechanism used while trying to acquire a lock - passing a |
Again, I haven't run it but awaiting gc before const retrieved = await storage.getMany(cidsGenerator())
await helia.gc() // might cause deadlock?
const firstEntryFromRetrieved = await getFirstEntry(retrieved) |
@whizzzkid : what is motivating this work? I'm not seeing any discussion in the PR or to a linked issue. I'm not saying we shouldn't do the work, but it would be good to have the context on why we're prioritizing this currently. |
Signed-off-by: Nishant Arora <[email protected]>
fbeed88
to
9f9bc60
Compare
Is this still relevant to keep open given 4 months in draft? |
## [@helia/ipns-v1.1.4](https://github.com/ipfs/helia-ipns/compare/@helia/ipns-v1.1.3...@helia/ipns-v1.1.4) (2023-09-11) ### Trivial Changes * update project config ([#99](ipfs/helia-ipns#99)) ([a704fdc](ipfs/helia-ipns@a704fdc)) ### Dependencies * bump multiformats from 11.0.2 to 12.0.1 ([#57](ipfs/helia-ipns#57)) ([6f93e51](ipfs/helia-ipns@6f93e51)) * **dev:** bump aegir from 39.0.13 to 40.0.8 ([#65](ipfs/helia-ipns#65)) ([174987b](ipfs/helia-ipns@174987b))
I'm going to close this because there's been no movement in almost a year. I think yes, if you mis-use async generators you can get yourself into trouble but this is a bug in the consumer's code, not the internal implementation. |
the test case passes, but it shouldn't as the lock is still acquired? Reading more into how mortice works, maybe the test is not running in the WebWorker context.
:thinking-face: