Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Practical advantage of promises in shiny? #52

Closed
stefanoborini opened this issue Aug 13, 2019 · 4 comments

Comments

@stefanoborini
Copy link

commented Aug 13, 2019

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.

Thanks

@jcheng5

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

Hi there!

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

@jcheng5 jcheng5 closed this Aug 13, 2019

@stefanoborini

This comment has been minimized.

Copy link
Author

commented Aug 13, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

There's a single event loop handling all sessions. The event loop itself is never suspended. When Shiny sessions have pending promises (that they know about) they just set a flag on themselves to queue input/output until the flag is unset.

@stefanoborini

This comment has been minimized.

Copy link
Author

commented Aug 16, 2019

@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,

  • either something must have picked the future and added its completion to a queue, so that the event loop can trigger the then() functions in the main process, or
  • futures must post to the event loop themselves an event, but I don't see how this is achieved, as futures is not a strictly shiny feature, so it cannot know about the existence of such API.

It's quite impressive as a design, but there's a lot of magic happening and I am trying to understand it better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.