Signal progress when compiling for wasm32
bnjbvr opened this issue · comments
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 Option
al 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 asignal_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 :-)
Thoughts?