Failed device creation with device lost callback mode = WaitAnyOnly.

[lokokung]

As per the title, if we try to create a device but fail with a DeviceDescriptor that has a deviceLostCallbackMode = WaitAnyOnly, the callback will be effectively leaked until the Instance is destroyed because the only way to make that callback fire would have been to call WaitAny on the wgpu::Future we get from device.GetDeviceLostFuture(), but given that the device creation failed, the RequestDeviceCallback will pass nullptr for the Device, and hence the user will never have a way to call device.GetDeviceLostFuture().

[eliemichel]

But in the end the callback will still be called exactly once, right? When the instance is destroyed, the lost callback is still pending (although ready to fire) and thus invoked with status "Canceled".

You might have a practical use case in mind for which it is a problem (if so, we can discuss it), but at least I think the current behavior of the API is consistent.

[lokokung]

Yea, the callback will be fired when the Instance is dropped, but as a user, it would be an allocation that is effectively leaked until then and you have no way to control it. My initial thought was maybe we just shouldn't allow the device lost event to be WaitAnyOnly, and force it to be at least AllowProcessEvents. That way, users can at least flush it by calling ProcessEvents.

[eliemichel]

If that bothers you for your use case, you can indeed use AllowProcessEvents, but I don't see a reason to force everybody else to adopt the same idiom. The behavior in case of WaitAnyOnly is valid and consistent with the rest of the API so it probably won't come as a surprise for the user. There is no leak per se since the callback ends up being called (I get that it can feel like a leak if you try to create devices many times during the lifetime of your instance, but not everybody does that).