-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The case for a context object #1390
Comments
Short answer: It's faster and simpler, and that is just how it was originally written. Long answer:
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
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. |
Now I know semgrep, this should be easier. My prior attempt at making GC functions use a context: #1199
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 If the host language has its own event loop thread-switching (like Go), then the current API cannot be used easily (need |
@iacore Yo, um, I looked into semgrep and it looks impenetrable. Would it be more work for you to explain to me how to do this or to do it yourself? |
Also, nice. Ziguanas stand up. |
How to use semgrep: If you have VSCode,
Still, @bakpakin, will you accept the major change in context passing style? (like, @welcome-linja, that's why i did not do the change already)
|
Probably not, as it breaks the interface pretty badly. The existing interface for loading and saving the VM should be enough. For example, every utility function that creates strings or similar like janet_ckeywordv will need to take a context object. |
Among embedded scripting languages, Janet is as far as I know joined only by Chez Scheme in storing VM state statically, rather than as an opaque context object passed by handle to API functions. The rationale given for this on the website is that C has no type-namespaced functions, so a context object is another parameter to every API call, which is clutter.
However, as also noted on the website, this confines VMs to threads, which causes problems when one VM doesn't necessarily stay on one thread or have a whole thread to itself:
A context object would solve these problems, but of course introduce problems of its own:
I won't be so arrogant as to assume I know what's best, but personally I feel that a context object is the more correct solution. And if we agree, I think it's better to do it sooner rather than later.
The text was updated successfully, but these errors were encountered: