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.