The case for a context object

The case for a context object

[bakpakin]

Short answer: It's faster and simpler, and that is just how it was originally written.

Long answer:
These are all good points, but at the end of the day I'm not really confident that a rewrite is worth it. Also usually this sort of things causes a perf hit due to extra state being passed around everywhere, or the presence of extra pointer dereferencing and extra arguments. If I were to start over from scratch I might create a global context object (mostly for ease of implementation, the creation of sub-contexts is straightforward), but there are downsides. And just because a context object would help people attach custom Zig and C++ event loops doesn't mean that that is a good idea - Janet has it's own and they would conflict (the whole idea of frameworks with pluggable event loops seems completely insane to me).

Coroutines on a multithreaded event loop, à la Zig, C++: there was previously discussion of a save/restore mechanism that would address this

Since Janet comes with it's own event loop (for better or for worse), this is really not something I want to address. However, save restore functionality works right now with janet_vm_save and janet_vm_load (see state.c). As pointed out though, this is not quite as nice if you are for some reason trying to embed in strange way. I feel like there is some circumstances where this just doesn't work but I can't think of any offhand.

And if we agree, I think it's better to do it sooner rather than later.

Unfortunately, it's not that soon from my perspective. This kind of argument always comes up when people are new to a project. That said, I think it would be a moderate but tedious effort to thread the JanetVM * object as the first argument to all functions, and then some more effort to make some things more idiomatic (I would also be curious on the perf impact - my guess would be small but measurable, like 5%).

But I think you will also find that certain things like signals require setting up some implicit global or per-thread state anyway.

[iacore]

That said, I think it would be a moderate but tedious effort to thread the JanetVM * object as the first argument to all functions, ...

Now I know semgrep, this should be easier.

My prior attempt at making GC functions use a context: #1199

Since Janet comes with it's own event loop (for better or for worse), this is really not something I want to address.

I often use Janet to process data, and the event loop is not needed. One example project I have is an HTTP server that runs some processing (need JanetVM) on every request. The current is API is usable, but I often forget to switch VM so I ended up creating a new VM on every request.

The language I use has defer so I can use defer c.janet_vm_save(&vm);. In C, error handling would be messier, since you have to save the VM state if you want to use it further (other requests might reset thread-local VM).

If the host language has its own event loop thread-switching (like Go), then the current API cannot be used easily (need janet_vm_save/load on context switching).