Skip to content
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

Inconsistent behavior when running in browser (and web worker) #175

Open
Pkcarreno opened this issue Apr 16, 2024 · 3 comments
Open

Inconsistent behavior when running in browser (and web worker) #175

Pkcarreno opened this issue Apr 16, 2024 · 3 comments

Comments

@Pkcarreno
Copy link

Pkcarreno commented Apr 16, 2024

The behavior of the library is not consistent depending on which browser scenario is running and how the quickjs invoker is exported.

Reproductions

For these examples, I'm using the quickjs-wasmfile debug and release packages + quickjs-emscripten-core, this with Vite.

I started from the vite+vue example but used React for convenience, however the framework is irrelevant for this demo.

web worker + direct export: https://stackblitz.com/edit/vitejs-vite-lw9djp?file=src%2Futils%2Fquickjs.ts

web worker + indirect export: https://stackblitz.com/edit/vitejs-vite-dbb3bd?file=src%2Futils%2Fquickjs.ts

same thread (browser) + direct export: https://stackblitz.com/edit/vitejs-vite-u4yz3c?file=src%2Futils%2Fquickjs.ts

Note: test this in chromium based browser, in Firefox this example does not work properly in Stackblitz. The execution in chromium based browser has the same behavior as in local execution.

Important: in each example, in the file src/utils/quickjs.ts there is commented code to test the release or debug version respectively, I thought it was better this way because it is understood that the code environment is the same and only changes the wasmfile package to be used.

These demos are conformed according to:

  • Execution environment:
    • Web worker
    • Same thread (browser)
  • According to how quickjs is exported:
    • Direct export:
      export const QuickJS = await newQuickJSWASMModuleFromVariant(variant);
      
    • Indirect export:
      export async function loadQuickJS() {
        return await newQuickJSWASMModuleFromVariant(variant);
      }
      

Explanation

From these examples, 2 errors arise, the first one is when using the debug version of the wasmfile, in all cases it throws an error Aborted(Assertion failed), I tried to trace this error, but I only ran into emscripten forum feedback and I have skill issues to go deeper.

On the other hand, when using the release version of the wasmfile the behavior is slightly different. In the scenario web worker + indirect export and same thread + direct export (presumably also the scenario same thread + indirect export) works as expected, but in the scenario web worker + direct export there is an error in the execution, the strangest thing is that this error does not give any output, and even never gets to run the web worker, my hypothesis is that the error happens when declaring the QuickJS variable in the file src/utils/quickjs.ts and when it is imported in the first lines the error occurs and stops the execution of the script completely, without returning any type of error or executing any log.

Note: if I leave the direct export line in the indirect export demo the same error happens as in the case of the web worker + direct export example, even if the loadQuickJS function is being called in the src/utils/eval.ts file.

My questions about this are:

  1. Is the debug version supposed to be used in the development environment of an external project that uses the library (quickjs-emscripten)?

  2. Why in the direct export example does it work when running in the same thread but not in the web worker (in the case of the wasmfile release version)?

In case it is an intentional behavior or not, it would be useful to clarify this behavior in the readme, I will collaborate with this according to the conclusions that will be reached here.

P.S: I know that this explanation may sound a little bit tricky, if you need me to expand on any specific topic I will be happy to clarify it.

@justjake
Copy link
Owner

My intention is that the library should just work for all the options you describe. Debug is intended for development/test of consumers, it should work for you.

To set expectations, I’m unlikely to have time to investigate your errors for a while. I haven’t tried web workers.

@Pkcarreno
Copy link
Author

Hey @justjake, don't worry, I'm just experimenting with the library, nothing serious yet. Take your time.

For my part I will try to help with the JS side, C/C++ is a bit beyond my skills.

I will recreate those demos using webpack to check that the behavior is the same and discard Vite's fault. I will update when I have them.

@Pkcarreno
Copy link
Author

Sorry for the delay, I've had problems recreating the demos with webpack, maybe it's a skill issue, I can't get the wasm path in the same way as in vite. Any tips would be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants