Held lock on worker and garbage collection

[saschanaz]

Given this code:

new Worker(URL.createObjectURL(new Blob([`
  navigator.locks.request("foo", () => new Promise(() => {}))
`])))

I found that this causes a held lock that is never released on both Firefox and Chrome, which means the worker itself is also kept alive because of that lock.

I'm not sure this is a preferable behavior, should a held lock prevent garbage collecting a worker?

[inexorabletash]

I'd agree that doesn't sound good. I don't have a good sense of what the implicit "strong references" are that causes this behavior, either in the abstract/spec space or in implementations. Which implies I don't know which references we'd need to explicitly weaken to prevent this.

(BTW, are you sure that in implementations it's truly the lock itself? Just verifying, I haven't dug in or tried it. If the promise resolves on a timer, does the worker get GC'd after the timer fires?)

[saschanaz]

I'd agree that doesn't sound good. I don't have a good sense of what the implicit "strong references" are that causes this behavior, either in the abstract/spec space or in implementations. Which implies I don't know which references we'd need to explicitly weaken to prevent this.

Same, we'll have to investigate 😄 (Edit: I mean spec-wise. I investigated why it happens in Gecko)

(BTW, are you sure that in implementations it's truly the lock itself? Just verifying, I haven't dug in or tried it. If the promise resolves on a timer, does the worker get GC'd after the timer fires?)

For Gecko I can confirm it's the lock. I'm not sure about Chrome, I only checked that locks.query() still has the held lock after gc() enabled by ./chrome --js-flags="--expose-gc".