Why Thread Local? Technical question about reactivity implementation

[markmals]

Hello! I'm a big admirer of Leptos and everything you've accomplished with it. I've also been a long-time fan of Solid.js and fine-grained reactivity systems in general.

I'm currently attempting to implement a signals reactivity system for Swift in order to pave the way for a future SwiftWasm or AdwaitaSwift fine-grained renderer. I figured I would try to follow the Leptos implementation as closely as possible since Swift and Rust share many traits in common. As I was working through it, I encountered this section of code, where the global OBSERVER variable is created as a thread-local variable:

thread_local! {
    static OBSERVER: RefCell<Option<AnySubscriber>> = const { RefCell::new(None) };
}

I've seen this technique used for the global "reactive context" variable in other languages as well, but since a Swift concurrency compatible analog of thread_local! isn't available in the Swift standard library and would be complex to model from scratch, I'm curious: Why is OBSERVER a thread-local value instead of, say, a process-global with a lock or some other synchronization technique?

[benwis]

Hiya! Since Greg is on vacation, I'll take a shot at a rough answer. We use thread locals mostly to keep the reactive runtimes created for each request separate from each other. Earlier Leptos versions didn't use them and instead created a separate Runtime struct for each request and stored references to it. I don't see a reason you couldn't switch to a different primitive

…

On Fri, Aug 9, 2024, at 7:26 PM, Mark Malstrom wrote: Hello! I'm a big admirer of Leptos and everything you've accomplished with it. I've also been a long-time fan of Solid.js and fine-grained reactivity systems in general. I'm currently attempting to implement a signals reactivity system for Swift in order to pave the way for a future SwiftWasm <https://swiftwasm.org> or AdwaitaSwift <https://www.swift.org/blog/adwaita-swift> fine-grained renderer. I figured I would try to follow the Leptos implementation as closely as possible since Swift and Rust share many traits in common. As I was working through it, I encountered this section of code <https://github.com/leptos-rs/leptos/blob/main/reactive_graph/src/graph/subscriber.rs#L5-L7>, where the global `OBSERVER` variable is created as a thread-local variable: thread_local! { static OBSERVER: RefCell<Option<AnySubscriber>> = const { RefCell::new(None) }; } I've seen this technique used for the global "reactive context" variable in other languages as well, but since a Swift concurrency <https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency> compatible analog of `thread_local!` isn't available in the Swift standard library and would be complex to model from scratch, I'm curious: Why is `OBSERVER` a thread-local value instead of, say, a process-global with a lock or some other synchronization technique? — Reply to this email directly, view it on GitHub <#2807>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBTCLX6AJNMS7UW345XPTZQV25RAVCNFSM6AAAAABMJNH426VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGAZTEMBVGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[markmals]

Thank you! I think I'll proceed with a lock, in that case.

[gbj]

OBSERVER here is thread-local rather than global because this allows running multiple observers in parallel, on platforms which support multithreading. OBSERVER is "what is the current observer while whatever code is running, is running?" If you have a global OBSERVER with a lock, only one thread can be running an effect (or computing a memo, etc.) at a time. If you have a thread-local OBSERVER, each thread can be running an effect (computing a memo, etc.) in parallel.

If you don't plan to support multithreading it shouldn't matter. If you do, it does!

[markmals]

Is your primary use case for multithreading multiple requests coming into the Leptos server? I can see that eventually being a goal for my project, but initially I want to focus on client-side interactions, both on the web and on native platforms. I'm not sure I would get the same benefit from being able to have multiple threads running memos or effects in parallel, since they would all eventually have to be run on the main thread anyway in order to update the UI.

Do you think this is as useful outside of a server contexts with multiple requests coming in from different people at the same time that might be entirely separate?

[gbj]

Note that while render effects that update the UI may need to run on the main thread, there are lots of other things that can reasonably be parallelized, especially memos/CPU-intensive derived computed work and non-UI effects (logging, network requests, etc.)

Ultimately though the reason this is thread-local is that it only ever needs to be thread-local, and that updating a thread-local variable with no need for synchronization is strictly better than a global variable with a lock. It's kind of that simple from my perspective.

[markmals]

Oh! Interesting… So is it possible for, let's say, a memo to be part of two different reactive graphs, one on a background thread and one on the main thread? So you could have a signal on the main thread being written to by user interaction, which is then read by a memo on a background thread and used to compute some expensive memoized value, and that memo is then read by a render effect on the main thread which updates the UI?

[gbj]

Yes, that's possible.