Use Threads.@spawn in refresh_until_synced_asyncmany#184
Conversation
Closes JuliaPluto#146. The function name signals parallelism intent. `@async` schedules on the current thread, so the loop was concurrent but not parallel; on multi-threaded Julia (default since 1.9 with `--threads=auto`), `Threads.@spawn` is the correct primitive for this `@sync for` fan-out and matches the function's name. Behavior with a single-threaded runtime is unchanged. The work inside `refresh_until_synced` already takes `withlock(notebook_sessions)` around shared state, so no additional synchronization is required.
|
Hey! Thanks for your interest! Can you write a bit about who you are, how you use PlutoSliderServer and your motivation to open this PR? |
|
Sorry, I meant to write this as a draft. I'm a hobbyist and have been experimenting with Julia to create a chem sim application for drug discovery and other work. Admittedly, I have been vibe coding a lot of the code and backtracking to learn. I wanted to see if I could help improve the upstream ecosystems for my projects for better adoption rates overall. |
|
Alright! For this issue we really need someone to dive into this to learn how threading works in Julia, and to see what our requirements are to make a decision. It's not just about the actual code change. If you are interested, feel free to keep investigating! |
|
Will do, sorry I had just started vibe coding and got a bit overzealous, making changes on a self hosted git server to test before I push upstream. |
2 participants
Closes #146.
The function name signals parallelism intent.
@asyncschedules on the current thread, so the loop was concurrent but not parallel; on multi-threaded Julia (default since 1.9 with--threads=auto),Threads.@spawnis the correct primitive for this@sync forfan-out and matches the function's name.Behavior with a single-threaded runtime is unchanged. The work inside
refresh_until_syncedalready takeswithlock(notebook_sessions)around shared state, so no additional synchronization is required.