adding a locking test case

[whizzzkid]

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:

[achingbrain]

I haven't run this test but from what I can see this passes because getFirstEntry breaks out of the await for..of which ends the generator and causes the lock to be released.

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 AbortSignal.timeout for example.

[achingbrain]

Again, I haven't run it but awaiting gc before getFirstEntry is called might do the same thing:

const retrieved = await storage.getMany(cidsGenerator())
await helia.gc() // might cause deadlock?
const firstEntryFromRetrieved = await getFirstEntry(retrieved)

[BigLep]

@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.

[BigLep]

Is this still relevant to keep open given 4 months in draft?

[achingbrain]

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.