How to obtain std.Io when executed as a dynamically loaded N-API Javascript library

Help
1

My entry point is effectively

fn NapiRegistrationEntry(env: napi.napi_env, exports: napi.napi_value) callconv(.c) napi.napi_value {
  // Initialize allocator
  // Set up UTF-8 locale
  // Register exposed functions.
  return null;
}

comptime {
    @export(&NapiRegistrationEntry, .{ .name = "napi_register_module_v1", .linkage = .strong });
}

I instantiate allocator as a global var, because the actual function invocations come from the JavaScript land. How do I obtain an instance of std.Io in these circumstances?

2

Are you trying to integrate with the JavaScript event loop, or do blocking operations?

3

Blocking operations would suffice for now, to get my stuff going. It would be great to integrate with the JavaScript event loop at some point in the future, but that’s a big stretch functionality-wise at the moment.

I’d image it should be possible to get Zig’s io_uring buffer ring going independently from libuv’s ring? In that case I would be able to enjoy asynchronicity while in the Zig land, then .join and .flush before giving control back to JS?

4

certainly it should, although there isn’t really a single “Zig’s io_uring buffer ring” unless you set up your program for that to be true. navigating that well is i guess the crux of the issue here

5

You can use this to get started:

std.Io.Threaded.global_single_threaded.

It might be better though to have some kind of explicit one-time initialization that sets up your Io instance. This would be how you set the options such as Allocator for async frames, environment variables, or integrate with the js event loop.

5 Likes