You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 28, 2023. It is now read-only.
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 :-)
Thoughts?
The text was updated successfully, but these errors were encountered:
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 theGeneratorProgress
, and passed as anOption
al parameter toworker_fn
inlib/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 eachworker_fn
call. In the case of wasm, the notifier is passed to the oneworker_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
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.Thoughts?
The text was updated successfully, but these errors were encountered: