Hello again, What are my options for running a potentially lengthy process using Dancer? I'm adapting old CGI.pm-based code, which uses one of two techniques: 1. the CGI creates a job that it sends to an externally-managed queue; users have a workspace area where they can check to see if their job has finished; 2. the CGI keeps the connection to the browser open while performing the process using a hack involving sending small chunks of data from time to time. Another common technique (similar to 1 above) is to fork off a child process and have the browser periodically refresh the page, which triggers a check to see if the child process has finished (e.g. by checking for the presence of a results file) and the results can be loaded. Do Dancer2's delayed / async / non-blocking capabilities offer any additional ways to deal with long-running processes, or maybe a more elegant way to do option 2? Thank you for any information! Amelia. On 2 October 2015 at 10:50, Amelia Ireland <aireland@lbl.gov> wrote:
Hello,
I'm very interested in using Dancer2's streaming and async capabilities, and have a number of questions about using Dancer2 asynchronously:
- Does the whole app have to be written to be asynchronous / non-blocking? (I assume so)
- Do all apps running from the same .psgi file have to be non-blocking? E.g. in app.psgi:
builder { mount '/app1' => $nonblocking_app; mount '/app2' => $blocking_app; };
- Are hooks safe to use in a non-blocking Dancer2 app or do they introduce a blocking element?
- When I run the drums example in a browser (Safari), it waits until the entire drum loop has completed and then prints the content. Is that what is expected to happen? I expected the content to be written by the browser as it received it. The docs aren't very clear on what Dancer is actually doing under the hood -- it would be useful to have more explanation of what's going on. I'd be happy to write up something myself, but I don't know what's going on. ;-)
Thanks!
Amelia.