Javascript Instance freezes (shows instance inactive and dies) when calling long running WASM-binary

[seb2010]

Describe the bug
I am using a solver-library "glpk.js" (https://github.com/jvail/glpk.js/) to optimize the Grid consumption and feedin for a PV, Battery, Wallbox, optional-demand scenario. I use glpk.js as a solver which uses a WASM-binary underneath. When I fire up the "solve" command, it is expected to take some time, e.g. 5 minutes. When doing so, the javascript instance freezes, as it seems to be fully occupied with the WASM call and does not respond otherwise at all.

To Reproduce
Steps to reproduce the behavior:

1. install the "glpk.js" library, reference it in a script and create a large LP-model to be solved. ALTERNATIVELY I think you could call any long-running WASM-binary which does not respond for a long time.
2. The Javascript Instance will freeze and reset itself

Expected behavior
Any script should be encapsulated to not have the whole instance freeze-up or cause a restart. If there is a mechanism to identify non-responding script-threads, there should be an option or code-snippet to be inserted on a script level to deactivate such functionality or to tell the instance otherwise that the call and non-responsiveness is intentional.

Screenshots & Logfiles

Versions:
-Adapter version: v7.1.6

• JS-Controller version: 5.0.16
• Node version: v18.17.1
• Operating system: debian bullseye

Additional context
I believe this is not a glpk.js issue, but caused by the call of the WASM inside the library which renders the script unresponsive

[klein0r]

Any script should be encapsulated to not have the whole instance freeze-up or cause a restart.

That is already the case by using V8 Virtual Machine contexts

https://nodejs.org/docs/latest-v18.x/api/vm.html

[seb2010]

Hi @klein0r: I am trying everything with the VM-module, but it still seems to freeze the whole instance. Do you have an example?

[Apollon77]

Maybe we have a misunderstanding here. Even with running the scripts in a "VM" the nodejs process still has ONE event loop 8and not each VM has one or such) ... so if this ONE event loop gets blocked by such a module (and honestly ...blocking a Event looop in Node.js is generally a very bad idea!) then this will block all scripts.

I think the only option you have is to somehow run this using a "fork another nodejs process to run your calculation" amd use inter process communication or such to get the results back.

[seb2010]

HI @Apollon77: thanks for clarification. Therefor I am already running this one script in it's own instance. Problem now there is: a seemingly non-responding javascript-instance is eventually timing out and causing iobroker to restart the instance. This limits my solving time a lot. Is there a way to increase this instance no-response timeout before restart?

[Apollon77]

No, there is no way to change such things for just one instance ... No idea even if it can be changed at all ... and honestly it also makes no sense to have an iobroker adapter running which blocks anything. s said: write a small script and use sparn/fork whatever to run this as a side process, thats the easiest and most probably also the best way

[seb2010]

I'll give it a try! thanks