I realized while implementing #749 that it requires an exception to be thrown if the buffer is mapped.
I have been thinking for months that we already needed to track the buffer [[state]] on the client-side in a way that was multi-thread-synchronized. However I can't seem to find a good reason for it - map calls return asynchronously, and unmap and writeBuffer can both generate errors asynchronously. (Though note we already have most of the info on the state via the pending promise and the mapped data, anyway.)
Given this, I think writeBuffer should fail asynchronously if the buffer is mapped. This would match unmap() and the map calls.
@kvark
I realized while implementing #749 that it requires an exception to be thrown if the buffer is mapped.
I have been thinking for months that we already needed to track the buffer
[[state]]on the client-side in a way that was multi-thread-synchronized. However I can't seem to find a good reason for it - map calls return asynchronously, and unmap and writeBuffer can both generate errors asynchronously. (Though note we already have most of the info on the state via the pending promise and the mapped data, anyway.)Given this, I think
writeBuffershould fail asynchronously if the buffer is mapped. This would matchunmap()and the map calls.@kvark