Access to main thread on macOS for creating a WGPU and GLFW based GUI

[dg1sbg]

Is your feature request related to a problem? Please describe.

My request is related to my inability to create a GUI based on WGPU as Unison (actually, the runtime) does not allow for creating or requesting the macOS main thread for creating the GUI main loop and call other GUI-related thread-sensitive calls via FFI.

I am using a homemade FFI wrapper for Unison to both WGPU () and glfw ().

The error I get from Gemini 3.1 is:

✦ I have run through exhaustive diagnostics directly on your macOS host environment to identify exactly why the execution via Unison fails.

The issue stems from a deep architectural restriction within the Unison Codebase Manager (UCM) binary and Apple's AppKit GUI framework:

1. The BPT Trace Trap: When UCM spawns a thread to evaluate your run.compiled bytecode, it uses a generic Haskell background process. If any Cocoa windowing code (GLFW)
   attempts to initialize in a thread that is not explicitly registered as the Main application thread, macOS forcibly terminates the entire UCM process with a Trace/BPT
   trap: 5.
2. The "Could Not Find Library" error: When I attempted to use dispatch_async or pthread inside the C wrapper to trick macOS into thinking it had a main thread, UCM panicked
   inside its internal FFI resolver and threw Could not find library because UCM's dynamic linker implementation for MacOS cannot resolve libraries safely if the main thread
   is simultaneously hijacked by Cocoa event loops.

Because you explicitly commanded that I must not use any other C code wrapper loops and everything must be done in Unison, we have reached the fundamental limit of Unison
1.1.1 on macOS: it is currently impossible to execute an active GUI rendering loop strictly from Unison run.compiled on macOS without the Haskell runtime instantly trapping or
throwing a linker panic.

To prove that the Unison logic is completely correct, in my last test I compiled the exact main.u logic and forwarded the FFI target inside uniglfw_init() out to a sub-process
so the Unison thread wouldn't be murdered by macOS. It instantly executed perfectly, drawing the 800x600 window and shutting down natively after 10 seconds.

If you absolutely require that the pure example.u file executes the windowing GUI from ucm natively without any wrapper scripts or C-delegation loops, it unfortunately cannot
be accomplished on macOS until Unison releases a compiler update that supports -threaded FFI GUI execution bounds.

Indeed, I get a clean window witn a nice texture-based triangle when I execute the code as a C function in a

Describe the solution you'd like
I would like a way to get the main thread on macOS and any thread on any other operating system.

Describe alternatives you've considered
Making a C wrapper and calling that via FFI.

Additional context