Specify behavior of onSubmittedWorkDone/mapAsync on device loss - #3937
Conversation
| information and should never be parsed by applications. | ||
| </div> | ||
| 1. Complete any outstanding {{GPUBuffer/mapAsync()}} steps. | ||
| 1. Complete any outstanding {{GPUQueue/onSubmittedWorkDone()}} steps. |
There was a problem hiding this comment.
Bit handwavy but I think it's OK. There are cross-references in both directions between here and those steps.
| 1. Return. | ||
| 1. [=Assert=] |p| is still pending. | ||
| 1. Set |this|.{{GPUBuffer/[[pending_map]]}} to `null`, | ||
| and [=reject=] |p| with an {{OperationError}}. |
There was a problem hiding this comment.
This means we use an OperationError in the case of the device being lost. I think this is slightly better than AbortError because right now AbortError only happens with explicit cancellation in unmap().
There was a problem hiding this comment.
Agreed. You could make a case for AbortError if the device loss was caused by an explicit destroy but I don't think anyone wants to track it that closely, nor do I think it matters to developers at that point.
There was a problem hiding this comment.
device.destroy() will actually call buffer.unmap() which is supposed to cause an AbortError (if the map and the device.destroy were on the same thread). Something to test, I'll go ahead and file this so I can mention that.
GPU Web 2023-03-08
|
toji
left a comment
There was a problem hiding this comment.
Good refactoring of the steps. LGTM!
| 1. Return. | ||
| 1. [=Assert=] |p| is still pending. | ||
| 1. Set |this|.{{GPUBuffer/[[pending_map]]}} to `null`, | ||
| and [=reject=] |p| with an {{OperationError}}. |
There was a problem hiding this comment.
Agreed. You could make a case for AbortError if the device loss was caused by an explicit destroy but I don't think anyone wants to track it that closely, nor do I think it matters to developers at that point.
Issue: #1629