Future, async, and promises: basic questions

shiny
1

I just found this terrific video from the 2018 RStudio Conference on the upcoming asynchronous possibilities in Shiny.

A couple of questions:

Does Future() actually do what's described in the video if Shiny Server is running on an inexpensive AWS instance with only one core?

I really need this for -- believe it or not -- sending email with the mailR package, which blocks everything else for about 10 seconds. But what happens if the user enters email text, clicks send, and then ends the session before the Future(send.email) has completed? Does ending the session end the Future process, too? Or does the session wait for the Future process to finish and allow somehow dealing with any errors?

Tom

2

Noticing that Joe has been active lately, I'd like to bump this question from a couple a weeks ago back to the top of the queue. - Tom

3

Thought I'd bump this to the top of the queue again to see if anyone knows the answers yet.

4

Have you seen the promises documentation site?

For this question, does the part in topic #5 about the flush cycle help at all? (But NB the strong recommendation to read through the topics in order)

As for the first question,

I don’t see that explicitly addressed anywhere, but you might get some clues from studying the details in Launching tasks, and the further information from the future vignette

Also, given your use case, this bit seems pretty important to note:

While promises can make a huge difference in the scalability of a Shiny app, they make relatively little difference in the latency of a single session. That is to say, if a Shiny application is slow when only a single user is hitting it, converting it to use promises is unlikely to make it perform any faster (and in fact may slightly slow it down). Promises will just help prevent other sessions from being slowed down by one session’s computations.

[…]

DON’T use promises to improve the performance of Shiny apps for a single user.

1 Like
5

Thank you very much for your response. I hadn't previously seen anything but the video.

You are correct that the answer to this question seems to be in the section of the documentation on Launching.

multisession: Launches up to n background R processes on the same machine (where n is the number of processor cores on the system, minus 1). So if an AWS instance has only 1 core, n is 1. And the number of launched background processes is zero. Then there's multicore, which seems to imply by its name that more than one core is required. The final option, multiprocess, appears to auto-select one of the first two.

Hope I'm wrong, since Linux itself seems able to run multiple processes on a single core without letting one of them capture the entire computer for extended periods of time.

The best answer to my particular problem is probably to switch out the mailR package with a direct connection to the Amazon Simple Email Service API, which should be much faster. But I haven't yet figured out how to create the security token the API requires.

6

Author of the future package here: You can force a single background worker on the local machine, regardless of what future::availableCores() reports, by using:

plan(cluster, workers = "localhost")
3 Likes