In native mode, progress can be signaled to the user by passing a GeneratorProgress implementation. The WebAssembly mode doesn't support signaling progress, which looks like a not-implemented-yet situation rather than something impossible to solve. So I'd like to add this :-)
Describe the solution you'd like
The code used to compute the current progress percentage could be generalized into a small notifier (not a final name!) data structure/closure wrapping the GeneratorProgress, and passed as an Optional parameter to worker_fn in lib/src/ms.rs.
The main progress loop in the worker would signal progress, if the parameter is not None. In the case of native, a None argument is passed to each worker_fn call. In the case of wasm, the notifier is passed to the one worker_fn call. This is future-proof in the sense that even if wasm multi-threading support was added, the borrow-checker would complain about multiple mutable ownership of the notifier.
Describe alternatives you've considered
the above solution is the path of least resistance, but it'll a dynamic check (to check if the Option is some) for each iteration of the progress loop, in both native and wasm. With a little effort, maybe the worker_fn function could be refactored in such a way that it's not a closure anymore. Then this function could be parameterized on some new trait with a signal_progress method; in the case of native, the trait impl would do nothing; in the wasm case, the impl would actually report progress. This is slightly more involved, but would imply no additional cost for the native case. I didn't look into this before getting any numbers with the suggested approach to confirm that the overhead is an actual issue.
implementing threading support for the wasm case. Ahem :-)
In native mode, progress can be signaled to the user by passing a
GeneratorProgressimplementation. The WebAssembly mode doesn't support signaling progress, which looks like a not-implemented-yet situation rather than something impossible to solve. So I'd like to add this :-)Describe the solution you'd like The code used to compute the current progress percentage could be generalized into a small
notifier(not a final name!) data structure/closure wrapping theGeneratorProgress, and passed as anOptional parameter toworker_fninlib/src/ms.rs.The main progress loop in the worker would signal progress, if the parameter is not None. In the case of native, a
Noneargument is passed to eachworker_fncall. In the case of wasm, the notifier is passed to the oneworker_fncall. This is future-proof in the sense that even if wasm multi-threading support was added, the borrow-checker would complain about multiple mutable ownership of the notifier.Describe alternatives you've considered
worker_fnfunction could be refactored in such a way that it's not a closure anymore. Then this function could be parameterized on some new trait with asignal_progressmethod; in the case of native, the trait impl would do nothing; in the wasm case, the impl would actually report progress. This is slightly more involved, but would imply no additional cost for the native case. I didn't look into this before getting any numbers with the suggested approach to confirm that the overhead is an actual issue.Thoughts?