Timon
Timon
#2539 should have solved this
At the Moment: If you have a reactivity graph you will eventally run into things like the [Diamond Problem](https://de.m.wikipedia.org/wiki/Diamond-Problem). These Problems are solved out of the box in MemoizR ([Signal](https://www.solidjs.com/tutorial/introduction_signals)...
Big advantages come from features that will be possible to implement with MemoizR that do not fit into the ReactiveX model. For example: - Structured Concurrency enables much more control...
I am working on a solid.js and structured concurrency inspired signal (reactivity/declerative) implementation for c#. I already have a thread-safe solid.js implementation in a synchronous/sequential version of this: This is...
I have a version that seems to work with [Recursion](https://learn.microsoft.com/en-us/dotnet/api/system.threading.lockrecursionpolicy?view=net-7.0#system-threading-lockrecursionpolicy-supportsrecursion). It works with [AsyncLocal](https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?view=net-7.0) and therefore can only work if there always is a [AsyncStateMachine ](https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.asyncstatemachineattribute?view=net-7.0) present when used. In...
> It was removed in v5 (See #97). > > Alternatively, you can use the `AsyncReaderWriterLock` from my ProtoPromise library that supports upgradeable lock. https://github.com/timcassell/ProtoPromise#asyncreaderwriterlock Thank you for this input,...
>as mentioned in the Readme of [AsyncReaderWriterLock](https://github.com/timcassell/ProtoPromise#asyncreaderwriterlock) Similar to System.Threading.ReaderWriterLockSlim, except, just like AsyncLock, recursion is not supported. Also, unlike ReaderWriterLockSlim, this is a balanced reader/writer lock. That means readers...
> My balanced implementation prevents starvation from either side. And even with that, you can still have many simultaneous readers. I agree in general this is probably the safest way...
> Unfortunately, we're already past that point in C#, and we'd need a new language I don't think that this is true. You can shoot yourself in the foot with...
> pending promise state can be propagated through the dependency graph Not only the promise state would be of interest. There will be a need to cancel all pending evaluations....