For anyone interested, I was able to solve this problem by refactoring my code to run a series of jobs with single responses in a persistent worker rather than one long job with many provisional responses. That way I can check a cancelled variable in the main thread before running each job. Unfortunately this approach has longer total runtime but the tradeoff is acceptable for me.
Le mar. 26 oct. 2021 12 h 44, Ben Wiley <[email protected]> a écrit : > I have a program compiled with Emscripten to WebAssembly. Every time I > start processing data (which can take awhile) I spin up a worker with > emscripten_create_worker. And I give the user an option to cancel. But if > the user starts and stops the work repeatedly we can end up with several > concurrent workers, despite only the most recent worker being valuable. On > mobile platforms I'm able to make the program run out of WASM memory by > quickly cycling between start/cancel even though I allow the program to > dynamically grow memory. > > I tried killing the worker on cancel using emscripten_destroy_worker, but > when I profiled my program afterward with Chrome performance tools, I saw > that the workers continue to run to completion, in concurrence. In other > words it seems like emscripten_destroy_worker isn't doing anything. > > Is there a secret to killing a worker that is still running? Do I need to > sleep in the middle of execution? > > Ben > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAOD6y0iG_kzqKxnmYk5N6R3rVUr7iEJB6MUp53%2BbPOmuaXssfg%40mail.gmail.com.
