Make it possible to declare ASYNCIFY_IMPORTS via a JS library annotation?

[juj]

I have an asynchronous JS library function:

C:

void navigator_gpu_request_adapter_async(WGpuRequestAdapterCallback adapterCallback);

JS:

  navigator_gpu_request_adapter_async: function(adapterCallback) {
    navigator['gpu']['requestAdapter']().then(adapter => {
      {{{ makeDynCall('vi', 'adapterCallback') }}}(wgpuStore(adapter));
    });
  },

To make it possible to synchronously initialize a WebGPU adapter, I want to use ASYNCIFY, so I create a new variant of this function, navigator_gpu_request_adapter_sync that reads

C:

WGpuAdapter navigator_gpu_request_adapter_sync(void);

JS:

  navigator_gpu_request_adapter_sync: function() {
    return Asyncify.handleAsync(() => {
      return navigator['gpu']['requestAdapter']().then(adapter => {
        return wgpuStore(adapter);
      })
    });
  },

and build with -sASYNCIFY=1 linker flag.

However, at runtime I get the error:

Uncaught Error: import navigator_gpu_request_adapter_sync was not in ASYNCIFY_IMPORTS, but changed the state

Reading the documentation, the currently intended way to fix this would be to add the linker flag

-sASYNCIFY_IMPORTS=['navigator_gpu_request_adapter_sync']

However I would not like to do that, because of the two problems:

1. it leaks abstractions to the user. Any user of my lib_webgpu.js library will need to know/remember which functions need to be annotated with -sASYNCIFY_IMPORTS when they build their program. I.e. one more thing for them to remember to do.
2. if the users have their own asyncified functions, concatenating/merging lib_webpu.js asyncify imports and their own asyncify imports is not currently possible, i.e. I cannot document them to blindly pass -sASYNCIFY_IMPORTS=['a','b','c'] to their link line, since if they have their own ASYNCIFY_IMPORTS as well, either they will override my imports (hence having no effect), or my documented line will replace their imports (breaking their asyncified functions).

Instead, I would like to declare the function to be asynchronous in my JS file

  navigator_gpu_request_adapter_sync__asyncify: true, // Declare this function to require asyncify
  navigator_gpu_request_adapter_sync: function() {
    return Asyncify.handleAsync(() => {
      return navigator['gpu']['requestAdapter']().then(adapter => {
        return wgpuStore(adapter);
      })
    });
  },

This way both problems 1) and 2) would be fixed, without asking the people to need to know about the internals of my WebGPU JS library and have them manually maintain these types of lists when using the library.

Would this be feasible to implement? (or does it come down to the same JS library parsing order issue that deps_info.py has?)

[sbc100]

Sounds like a good idea to me. @RReverser has also asked for source annotations to make native functions in needed asyncify.

I think we are fine with ordering because the JS library is compiled during phase_emscript which happens before phase_binaryen (which run asyncify and other binaryen passes)

[RReverser]

Note that similar usecase is already solved via EM_ASYNC_JS macro I've added recently - it allows to declare JS functions that will be automatically added to Asyncify list, plus takes care of the wrapping. But yeah, it's not something available in Emscripten's JS libraries at the moment.

[sbc100]

Oh interesting.. it looks like one could already piggyback on what you did and just start give the function a name that starts with with __asyncjs__:

emscripten/src/library_async.js

Lines 79 to 80 in 69409a6

	var isAsyncifyImport = ASYNCIFY_IMPORTS.indexOf(x) >= 0 ||
	x.startsWith('__asyncjs__');

But using the __asyncify tag in the library code sounds good.

[juj]

var isAsyncifyImport = ASYNCIFY_IMPORTS.indexOf(x) >= 0 || 
                        x.startsWith('__asyncjs__'); 

That raises two thoughts:

1. Doesn't that x.startsWith('__asyncjs__') break under Closure minification? Closure should be instructed never to minify any symbol that starts with __asyncjs__? (not sure if that's possible for Closure)

2. Is there a need to do this isAsyncifyImport check in release/production mode builds? Could that check be put behind ASSERTIONS?

[sbc100]

Oh yes, that code I linked to in emscripten/src/library_async.js is already inside of #ifdef ASSERTIONS so doesn't effect release builds.

The actual way this is handled is here:

emscripten/emcc.py

Lines 97 to 105 in cb545d9

	DEFAULT_ASYNCIFY_IMPORTS = [
	'emscripten_sleep', 'emscripten_wget', 'emscripten_wget_data', 'emscripten_idb_load',
	'emscripten_idb_store', 'emscripten_idb_delete', 'emscripten_idb_exists',
	'emscripten_idb_load_blob', 'emscripten_idb_store_blob', 'SDL_Delay',
	'emscripten_scan_registers', 'emscripten_lazy_load_code',
	'emscripten_fiber_swap',
	'wasi_snapshot_preview1.fd_sync', '__wasi_fd_sync', '_emval_await',
	'_dlopen_js', '__asyncjs__*'
	]

[RReverser]

Regardless of the resolution here, I would probably encourage looking into Embind's Asyncify integration added earlier as an alternative.

E.g. the code above

navigator_gpu_request_adapter_sync: function() {
    return Asyncify.handleAsync(() => {
      return navigator['gpu']['requestAdapter']().then(adapter => {
        return wgpuStore(adapter);
      })
    });
  },

Could be rewritten to retrieve adapter as val instance like this:

val adapter =
  val::global("navigator")["gpu"]
  .call<val>("requestAdapter")
  .await();

After this adapter is already a synchronous handle that you can invoke any other APIs on. This approach also doesn't require you to modify ASYNCIFY_IMPORTS.

[sbc100]

So far we don't have any emscripten-provided libraries that depend on embind.. so have webgpu depend on embind would be departure from that norm.

I'm not sure it makes sense to build our low level system libraries on embind since IIRC it can be somewhat heavy-weight. Perhaps we could land the version based on the __asyncify option then propose switch to embind as a separate issue where we can assess the cost/benefit.

[RReverser]

Hmm is that Emscripten-provided library? The only reference to wgpuStore I found is coming from this repo, which seems external? https://github.com/juj/wasm_webgpu

That said, given the amount of code I can see suggestion to use Embind is not very practical, as it would be very significant refactoring, so yeah, using __asyncify option makes sense.

[sbc100]

Ah I see, yes. Well I think my point still stands, maybe some folks want to use asyncify to its fullest without also using embind?

[RReverser]

Oh yeah, could be. The reason I suggested it in this case is because what wgpuStore does (https://github.com/juj/wasm_webgpu/blob/bba80ae7b0dc389f5b3bc05e6816af48781169d8/lib/lib_webgpu.js#L36-L63) is very close to replicating val's behaviour, and it seemed like a nice opportunity to kill two birds with one stone.

But then again, given the amount of code, I can already see it's infeasible endeavour.

[RReverser]

FWIW (again, doesn't solve the library use-case, just for the record) yet another alternative, this time without Embind, would be to use the mentioned EM_ASYNC_JS from C++.

Before:

navigator_gpu_request_adapter_sync: function() {
    return Asyncify.handleAsync(() => {
      return navigator['gpu']['requestAdapter']().then(adapter => {
        return wgpuStore(adapter);
      })
    });
  },

After:

EM_ASYNC_JS(WGpuAdapter, navigator_gpu_request_adapter_sync, (), {
  return wgpuStore(await navigator['gpu']['requestAdapter']());
});

[juj]

Thanks @RReverser for the suggestion. I am well familiar with embind, I was its maintainer for a while, and also commercially contracted in the past to develop embind back in 2013.

However for this purpose/project, I am not looking to build on top of embind as a dependency, but rather use the direct asyncify API.

Oh yes, that code I linked to in emscripten/src/library_async.js is already inside of #ifdef ASSERTIONS so doesn't effect release builds.

Thanks - that reveals I did not much look at the code, but just briefly glanced a few lines around the call site :)

[RReverser]

Thanks @RReverser for the suggestion. I am well familiar with embind, I was its maintainer for a while, and also commercially contracted in the past to develop embind back in 2013.

I'm aware :) But you might've not seen the Embind + Asyncify integrations or new Asyncify JS macros I've added during the last year, so it seemed worthwhile to point those out.