Stream: platform development

Topic: When host calls platform calls the host

Jasper Woudenberg (Dec 08 2024 at 10:27):

In working on my static site generator platform in Zig, I've a situation Zig code calls the platform, and the platform in turns runs an effect that calls back into Zig:

platform main  ->  exposed host main  ->  platform effect

I'd like my zig code in platform main to set some state that platform effect can use, Ideally without having to pass it through the host code because it would make the APIs for application authors much worse.

My current approach is that platform main writes to a global var that platform effect can read out of. That's going to be good enough for a long while, but will fall down if I ever introduce threads, so I'm curious if folks have ideas on what a better approach would be. Again, I'm not blocked, just curious!

Two possible answers that come to mind:

• Create/use some kind of per-thread storage and have platform code store/load data from that.
• Is this where effect handlers are goind to come in useful? I.e., when the platform initially calls into the host it will construct effect handlers for it that will have the shared context baked in?

Richard Feldman (Dec 08 2024 at 13:42):

threadlocal certainly sounds easiest! It's like a global except just for the current thread:

https://ziglang.org/documentation/master/#Thread-Local-Variables

Jasper Woudenberg (Dec 08 2024 at 15:03):

Neat!

Oskar Hahn (Dec 08 2024 at 15:11):

There is the idea, that when you call into Roc, you have to pass in the allocator and all callbacks, for effects: https://github.com/roc-lang/roc/issues/6382

With this feature, it will be possible to have the data in the function, that calls Roc.

Jasper Woudenberg (Dec 08 2024 at 15:38):

I like the threadlocal approach for its simplicity, but I guess the 'pass allocator and callbacks to roc' approach would be nice if I want to call platform code from a green thread.

Last updated: Jul 26 2025 at 12:14 UTC