On 12 August 2011 12:29, damien krotkine <dkrotkine@gmail.com> wrote:
On 11 August 2011 20:40, sawyer x <xsawyerx@gmail.com> wrote:
On Thu, Aug 11, 2011 at 9:37 PM, Colin Keith <colinmkeith@gmail.com> wrote:
On Thu, Aug 11, 2011 at 2:27 PM, David Precious <davidp@preshweb.co.uk> wrote:
On Thursday 11 August 2011 18:17:47 David Precious wrote:
Another possible alternative would be to fork a new process that will do the stuff in the background, whilst the original process continues
But as I thought about it a little more I realised that Dancer is usually used in an application situation (is it application, daemon, or some other term?) and so Dancer itself would keep running, unlike a CGI script, and so be able to manage the child processes. You could queue extra data if there are too many child processes or if the load is too high, etc. You shouldn't even need to serialize it as the OP mentioned unless it is large and you don't want it in memory or for data safety in case of a restart of the application.
Actually, since Dancer is run on top of PSGI (not necessarily, but mainly), it means that you could use the AnyEvent PSGI server and push stuff to be run in async, on your own.
That's a brillant idea, and probably the best compromise here. Forking has a high payload, but keeping a unique background child or using msg queues means serialization, which is not very convenient.
There is also the POEx::Role::PSGIServer module, to do the same in POE.