Just a few questions

[fedeAlterio]

Why opt for a fresh implementation instead of contributing to the existing R3/R3Async repositories? R3 already represents a modern reimplementation that addresses essentially all the limitations of classic Rx.NET, so it might have been a natural place natural place for further improvements or performance optimizations.

Regarding naming, “Signals” in the UI ecosystem is generally associated with automatic dependency tracking (for example, Angular, React or JS frameworks or in my own SignalsDotnet project), though I’m not entirely convinced that applies in this case.

One additional point: I noticed that SignalAsync implementation appear to draw inspiration from R3Async. A brief acknowledgment of that influence would likely not make a significant difference for the project itself, but it would have made a meaningful difference for me, since the implementation is not trivial, and it took some time.

Also, I noticed the use of ConfigureAwait(false). I don't Think this is a good choice, for reason I explained in R3Async readme.

Another thing. I think the way you check for re-entrance is wrong. I used async locals because they are restored between awaits, this is the only reliable way to do that. Checking for thread Ids in async code is not meaningful

but I would love to talk about that further 🙂

[glennawatson]

Signals implementation existed long before R3 in another project. Just a rename though. It existed in ReactiveMarbles and been around for years.

[glennawatson]

Hey @fedeAlterio

Thanks for the detailed write-up - taking the points in turn.

Why a fresh implementation rather than contributing to R3/R3Async. Different design center, not a competing one. Primitives is the ReactiveUI ecosystem's own low-level layer and it continues a Signal lineage that predates R3 in our repos (links below) — zero-dependency primitives, broad multi-targeting/AOT, and tight ReactiveUI integration. That's a different remit from R3, so carrying our own lineage forward was the natural path. Where interop matters we've built it explicitly - there's a dedicated ReactiveUI.Primitives.R3Bridge layer that adapts our async observables/observers to R3Async. We wanted to keep the IObservable<T> layer so that it minimised disruption to ReactiveUI as a whole.

Attribution / "Signals existed long before R3." The Signal model isn't derived from R3 or R3Async; it predates both in public ReactiveMarbles history:

• Sync Signal (renaming IObservable/IObserver -> ISignal with …Signal operators): reactivemarbles/Minimalist.Reactive@6ba92d5 — 2022-10-30 (repo created 2021-09-29).
• AsyncSignal / IAsyncSignal / Signal.FromTask: reactivemarbles/Signal.RxNet@63091a4 — 2023-03-11.
• For reference, R3's first release (0.1.0) was 2024-01-08, its announcement 2024-03-06; R3Async is later still. So SignalAsync is our existing AsyncSignal abstraction carried forward — naming and concept were in our repos ~10 months before R3 and over a year before R3Async. These are well-trodden Rx primitives on both sides; nothing R3Async-specific is borrowed. We've already added a bridge layer for R3 interop, and beyond that we don't see an acknowledgement as warranted.

Naming "Signals." The term is overloaded — in Angular/SolidJS it means auto dependency-tracking. Here "Signal" is our long-standing name (2021–2023, above) for the Rx Observable/Observer abstraction, not the auto-tracking UI-signal semantics. It's an established name across our projects and predates the recent UI-framework usage in our code.

ConfigureAwait(false). Deliberate: false is the standard guidance for a general-purpose library (don't capture/force a context callers may not have). Where capturing matters we make it configurable — e.g. command execution exposes ConfigureAwait(continueOnCapturedContext). R3Async made a different default for its own reasons; both are reasonable, and we're open to per-operator adjustments where context capture is genuinely needed.

Re-entrance detection. Good point. Our async operators detect logical re-entrancy with AsyncLocal<bool>, which flows across thread hops — agreed that's the right mechanism and that raw thread-id checks aren't meaningful for logical async flow. One place still keys on ManagedThreadId (the observer base's concurrent-call contract check); you're right that it doesn't generalise to async continuations, and we'll move it onto the same AsyncLocal-based approach. Thanks for flagging it.