Skip to content

Simple usage scenario for wgpuInstanceWaitAny vs wgpuInstanceProcessEvents #536

@eliemichel

Description

@eliemichel

As I am upgrading my WebGPU programming guide (WIP version), I am looking for the best way to progressively introduce methods for polling async operations.

The very first case of async operation is the adapter request, for which wgpuInstanceProcessEvents is the most straightforward/less verbose solution:

wgpuInstanceProcessEvents(instance);
while (!userData.requestEnded) {
    // Waiting for 100 ms to avoid asking too often to process events
    sleepForMilliseconds(100);
    wgpuInstanceProcessEvents(instance);
}

(I know in practice the very first wgpuInstanceProcessEvents invokes the callback and turns userData.requestEnded, but I'm playing by the standard.)

Now I'm looking for a "natural" way to introduce wgpuInstanceWaitAny in a case where it brings something that the wgpuInstanceProcessEvents pattern cannot do well. I can think of several reasons:

  • Using wgpuInstanceWaitAny makes it possible to query the completness of the WGPUFuture instead of maintaining my own userData.requestEnded. But this requires to hold the WGPUFuture, and to create the WGPUFutureInfo, so it ends up being more verbose.

  • Using wgpuInstanceWaitAny allows for more reactivity because the 100ms would become a timeout instead of being a non-breakable time increment. Of course it is important, but timed wait are not always available, so it is also verbose for something happening in an introductory chapter.

  • Using wgpuInstanceWaitAny may only invoke the callback associated with the queried futures. First, is that true? (ignoring the AllowSpontaneous ones ofc). And I don't have a simple scenario where this is needed.

  • Do you have other ideas? I am missing something obvious or is wgpuInstanceWaitAny meant for advanced use cases or to write the inner bits of abstraction layers?

Metadata

Metadata

Assignees

No one assigned

    Labels

    asyncAsynchronous operations and callbacksneeds docsNon-trivial API contract needs to be documented. Orthogonal to open vs closed; remove when doc'd.non-breakingDoes not require a breaking change (that would block V1.0)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions