-
Notifications
You must be signed in to change notification settings - Fork 21
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
Suggestions #160
Comments
Great suggestions, @dananderson!
|
We have this issue for esm. I'd also be into C99 NAPI, but I think it would take a little work. We mostly auto-generate bindings, so if you feel up to it, a PR to auto-gen that instead would be much appreciated. |
If I have some time next week, I will look into making a PR. Some other issues I found: examples/models/models_rlgl_solar_system.js does not work because the rl*() functions are not generated. All of the examples use a tight while loop, so the node event loop gets starved (never runs). When node runs the main script, it will drain the async jobs and then run the event loop. Since there is a tight loop in the main script, the async jobs and event loop never run. Consider this example:
The "read the file!" message prints AFTER r.CloseWindow(). That would include all I/O callbacks, timers, etc. Each iteration of the loop should be on a macro task (timer, setImmediate, etc). The tight loop cuts the examples off from much of the node async apis. Feel free to close, as this was just opened for some discussion. |
I have had issues with this in my own code, like if I try to use callbacks or async code or sometimes even just |
Ok, this issue can be closed. I can provide some insight into the node event loop in #134 |
I spent some time today getting this package working with https://github.com/lightsourceengine/veil (Node-like runtime written in C99). I got this package working and that support will be in the next release. In that work, I noticed a couple of minor things that can be improved:
Use the C N-API calls, rather than the C++ napi lib. napi adds allocations and wrappers to work with C++. Unless you are using classes, the overhead is not worth it. And, you will probably end up with a smaller .node file.
Consider exporting an ES module. You can setup the package.json to export a CommonJS module and an ES module. The CJS modules are legacy at this point.. and they are difficult to work with. CommonJS also have some loading overhead when imported.
The text was updated successfully, but these errors were encountered: