-
Notifications
You must be signed in to change notification settings - Fork 746
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
Wasm support #942
Comments
This does look interesting for sure. It seems all changes can be localized to a different platform enlightenment provider to tweak scheduling behavior via a custom CAL? Is there anything else needed besides this to get it working? Given we have enlightenments and custom CALs as an extensibility point, and this shows their usefulness, we should at the very least make sure that they cover everything that's needed to light up an environment like WASM such that the core of Rx remains the same across all plaforms, and just a tiny module needs to be installed to make it work in different environments. So, if there's anything missing, or something that looked particularly hard, we should address this first. Beyond this, we can consider if we want to support WASM out of the box as part of Rx releases. |
Hey @bartdesmet and thanks for your detailed reply. |
Hey @bartdesmet, aside from the custom enlightenment provider, there are no other changes that are needed at this point, aside from the temporary lack of threads for wasm. I can tell you that it works pretty well, we've been using @nventive a similar set of changes for a while now, and it works pretty well. It's obviously running all single-threaded so not all operators are functional (blocking ones, specifically), but the rest is behaving as it would on any .NET runtime that supports Rx. The only particularity is the fact that the Wasm scheduler (when no threads are available) requires the reset of a Threads support in mono-wasm will fix a lot of those temporary platform issues. I'm glad that you kept the extensibility mechanisms you put in place for supporting PCLs (way back now !), as it allows for this kind of new platforms support without having to alter Rx published packages, and their dependents. I'd be a good idea not to deprecate them :) |
Thanks for the prompt replies. First, sorry for the jargon. CAL stands for "Concurrency Abstraction Layer" and is the bottom-most layer of scheduler infrastructure, which seems was replaced for WASM. This is indeed a supported scenario, so I don't think there's much to do in Rx itself at this point. I'll make sure the support for enlightenment providers doesn't get dropped. A similar extensibility point to intercept query operators (for purposes of e.g. building debuggers) was being questioned in #540, so it'd good to see real-world use cases of these Rx 2.x facilities being pointed out here in the issue tracker. |
It seems to me such platform support can live outside dotnet/reactive, as demonstrated by the example provided given that we don't remove the various hooks and override possibilities (very unlikely to happen now). Also I presume there would be quirks to be worked around quickly due to platform bugs discovered or version changes which are much better handled via the dedicated external library. |
Hi,
Would you consider integrating WASM support based or not based on this repo (which based on this one)?
The text was updated successfully, but these errors were encountered: