Why is Adapter::request_device() randomly using Futures?

[AshtonSnapp]

This is extremely frustrating, I'm trying to get a project started up and the first roadblock is some random unknowable decision that I have no control over and no easy way to work around. I thought I was going to be writing nice, familiar, sync code, and then for some reason Adapter::request_device() uses futures. Of which I have no easy way of dealing with other than making a RawWaker, wrapping it in a Waker, wrapping that in a Context, and giving that to the poll method of the pinned future. Which is a lot of work to get the result out of one function that I am going to call once.

So, wgpu people, why did you do this? Why did you create this torture?

[kpreid]

Of which I have no easy way of dealing with other than making a RawWaker, wrapping it in a Waker, wrapping that in a Context, and giving that to the poll method of the pinned future.

You do not need to deal with raw wakers yourself; pollster neatly wraps all that up into an absolutely minimal but complete implementation of blocking on a Future.

why did you do this?

One of the primary purposes of wgpu is to be WebGPU — both an implementation of WebGPU, and an interface to the WebGPU API in browsers — and for that purpose, not just request_device(), but everything that retrieves information from the GPU or OS is asynchronous (though not necessarily async). The only blocking call anywhere in wgpu is Device::poll(Wait).