Is it possible to embed PerryTS in a host event loop (e.g. winit)?

[Alex6357]

Hi,

I'm building a native UI engine using winit as the host and PerryTS as the AOT-compiled logic layer. Since winit must control the main thread's event loop, I have two questions:

1. Can PerryTS compile files as a static library without the default main entry?
2. Does the runtime expose a C API to manually drive its internal event loop and flush microtasks from the host?

Thanks!

[proggeramlug]

Hi @Alex6357 — this is a great use case and exactly the kind of embedding scenario we want Perry to support well. Let me give you the honest current state, and then please do file an issue for the gap — we want to close it.

Q1 — static library without main: Not quite there yet, but partially possible:

• --output-type dylib is the closest fit today — it emits a .dylib/.so and replaces main with a perry_module_init entry symbol you can call from the host (crates/perry/src/commands/compile.rs, crates/perry-codegen/src/codegen.rs). For a winit Rust host this is workable right now: link against the dylib and call perry_module_init from your setup code.
• --no-link stops at .o files, but main is still emitted inside them, so it's not a clean answer.
• There is no --staticlib / --emit-archive mode yet — but this is a small, well-scoped addition (gate the main emission on output-type and pipe cc -c outputs into ar rcs), and your winit use case is a great motivation for it. Please open a feature request — I checked and there's no existing tracker for it. We'd be happy to prioritize it.

Q2 — driving the event loop from the host: Yes, this is supported today. The C-callable symbols (all #[no_mangle] extern "C" in crates/perry-runtime):

int  js_promise_run_microtasks(void);  // drains promises/timers/microtasks, returns count drained
int  js_microtasks_pending(void);      // 1 if queue has work, 0 otherwise
void js_gc_init(void);                 // call once at startup before any microtask run

A typical winit loop would call js_gc_init() once, then call js_promise_run_microtasks() from Event::AboutToWait (or on a timer), and use js_microtasks_pending() to choose between ControlFlow::Poll and ControlFlow::Wait.

One thing worth flagging early so it doesn't surprise you later: Perry owns its own tokio runtime internally, so socket-readiness on Perry-side I/O (HTTP, MySQL, etc.) won't wake your winit loop directly — completions surface on your next js_promise_run_microtasks() call. For UI logic + occasional async, that works fine. If you hit a case where you need tighter host↔Perry async coupling, file that too — it's a deeper change but worth tracking as a real requirement.

Summary: dylib + js_promise_run_microtasks() should unblock you today, and we'd love a tracking issue for the proper --staticlib output so we can get you off the dylib workaround. Happy to help scope it once you open it.

[Alex6357]

Hi @proggeramlug,
Thanks for your detailed guidance! I’ve just filed the issue #1088 to track the staticlib output and the unified FFI facade/wake-up hook.