Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Practical advantage of promises in shiny? #52
Sorry this is more of a question rather than an issue, but I could not get a definitive answer on other channels.
I am experienced with React and async under python. I am new to the world of R and Shiny.
I noticed from the documentation that a future must be completed when the iteration of the event loop is completed. There's thus the equivalence of a synchronization barrier that does not let the event loop proceed further in parsing events until all the future are resolved.
My question is: what is the final advantage of using an async approach in shiny? If I have a process that can take, say, up to two minutes (e.g. a network request timeout, or a heavy calculation), the event loop will be unable to process any further input for those two minutes. The only possible advantage is if multiple futures are spawned.
My goal is to replace HTML elements before and after an async operation, but it's a testbed for training in Shiny, not an actual problem I have to solve. I am not therefore looking for a workaround or solution, rather to understand the general concepts and preferred approaches.
It's not true that the event loop is blocked while a promise is pending. That really would be pretty useless
However to try to avoid forcing the app author to deal with race conditions, within a single session we suspend I/O with the browser until all pending promises have completed. While this does affect the kind of thing you're trying to do, it at least lets multiple sessions make progress simultaneously.
If you know what you're doing (and it sounds like you do!) then you can opt out of this session-level synchronization with a technique I posted in a comment on this issue: #23
Ok, thank you. On the internal design, just to understand, is there a single event loop handling all sessions, or each session gets its own loop on a separate thread/process?
I think I get the overall design now. In python terms, it's more like tornado, rather than flask.
@jcheng5 and I assume that Shiny learns about the pending futures because the server function returns them? If that's the case, as it seems to be from other posts that return NULL from the server function, how is it achieved that with "fire and forget" futures the then() function actually executes in the main thread? to do so,
It's quite impressive as a design, but there's a lot of magic happening and I am trying to understand it better.