Wasm support

[weitzhandler]

Hi,

Would you consider integrating WASM support based or not based on this repo (which based on this one)?

[bartdesmet]

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.

[weitzhandler]

Hey @bartdesmet and thanks for your detailed reply.
First of all, the way of extensibility I've found, is as you can see in the code, by explicitly setting the obsolete PlatformEnlightenmentProvider.Current with our custom IPlatformEnlightenmentProvider. Would be happy of better ways.
Apart from that, as @jeromelaban pointed out, there is a simple way to 'port to wasm', which is if we get an exception when trying to create a new Thread. It would definitely be nice if the functionality is baked in Rx itself. Otherwise, we're looking for nicer ways to plug in custom enlightenment providers.
P.S. I'm not sure what you're referring to by CAL.

[jeromelaban]

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 System.Threading.Timer instance (which maps to a JavaScript setTimout, and can be somehow costly. For the CoreDispatcher in Uno, we've had to use a special JS mixin that uses of the non-standard setImmediate function, which is a lot less costly, but requires the addition of a non-trivial piece of Javascript, something that mono does not provide an easy way to package, and that dependents such as Rx may not want as well.

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 :)

[bartdesmet]

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.

[akarnokd]

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.