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

Offline capability #25

Open
9SMTM6 opened this issue Sep 1, 2024 · 5 comments
Open

Offline capability #25

9SMTM6 opened this issue Sep 1, 2024 · 5 comments

Comments

@9SMTM6
Copy link

9SMTM6 commented Sep 1, 2024

Hey! I've been using this library for a bit now, and its really amazing for what it can do!

However, currently, when I open my project and then spawn a thread, each time there are still requests going out, so far that it doesn't work if my browser is offline (I also don't have a caching serviceworker, which might be able to help).

Precisely there's 4 requests going out, 2 of which transfer 0 bytes and still seem to work offline, 2 others where at least the first fails when offline.

To be entirely honest, I don't really understand the entire business with the js scripts thats described in the readme. However, it is my understanding that this is required because webworkers require to be started from a URL. BTW, the urls in that readme are dead, the paths they reference have changed. Its easy enough to find the correct files, but it might be worth a quick fix.

I did a bit of looking around, and this stack overflow question and answer imply that its possible to use a data-url for the serviceworker.

This should mean that its possible to do this request, from my understanding, without that complicated hack to get a url, and its possible entirely offline.

I'm uncertain whether this will actually enable everything to work offline. I'm under the impression that one of the 2 network bearing requests in my case is for the generated js-wrappers from wasm-bindgen.

But I hope that you may have more insight into that, and I thought perhaps you would be interested in using a data-url to avoid the current hack, even if this doesn't add any features.

@9SMTM6
Copy link
Author

9SMTM6 commented Sep 1, 2024

So yeah. Data URL doesn't help there, aside maybe from being able to replace the blob urls with the data urls, which avoids having to manage the blob resource.

Upon further inspection, it seems that these requests come in 2 pairs of blob url + request. One pair is the worker module polyfill. If I configure out that code, then I avoid one non-load-bearing and one load-bearing request. Which could be a PR btw. I was unable to remove the initial request, even with cfg_attr, but any subsequent request can be avoided.

The other part is the original wasm_bindgen shim. That load is triggered from the importScripts action in web_worker_module.js. The url gets inserted here.

I wonder why you don't url-encode the original shim and provide that url with search and replace? AFAICT, if you do that, and the same with the polyfill (or make it easy to configure out, as I was showing) then it should work out?

Currently you just encode the worker script itself, which, when compared to the wasm bindgen shim, should typically be much smaller.

@9SMTM6
Copy link
Author

9SMTM6 commented Sep 1, 2024

Another interesting thing to me, is that the wasm script only gets downloaded a single time. This should happen in the generated shim file. I would like to investigate what that script does to avoid another download for the worker. I can't even see a blob url request or similar.

@9SMTM6
Copy link
Author

9SMTM6 commented Sep 1, 2024

Another interesting thing to me, is that the wasm script only gets downloaded a single time. This should happen in the generated shim file. I would like to investigate what that script does to avoid another download for the worker. I can't even see a blob url request or similar.

My understanding is that the initialization code creates a global wasm variable, which seems to also be accessible from the worker(?!) which you then use in the wasm_thread_entry_point to immediately jump into wasm.

At least I cant find any root-level statements in my generated shim aside from the stuff at the very beginning, which only declares the wasm variable, but doesn't assign it. It only gets assigned in a function, that AFAICT only gets invoked in the main thread in the beginning.

So the wasm global is available in workers by default? I'd assume its a copy, if present, not shared?

@9SMTM6
Copy link
Author

9SMTM6 commented Sep 1, 2024

So the wasm global is available in workers by default? I'd assume its a copy, if present, not shared?

oops. I overlooked the init call in the worker script. Well, that explains parts.

@9SMTM6
Copy link
Author

9SMTM6 commented Sep 5, 2024

I've further investigated this. Solving this would be difficult, and the hack would remain. But it should be possible with a similar approach to whats done for the worker script, with a manual fetch request for the bindgen js file.

But it won't be easy.

I don't have the energy to do this. I've since reevaluated using serviceworkers for offline-capability and got things working to my satisfaction.

Feel free to close this, or keep it open if you care for it.

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

1 participant