in reply to How to fork in PSGI/Dancer2

We have a PSGI/Plack service (no Dancer nor Mojo involved, just StarMan) and it daemonizes a child in order to finish some processing that we don't want to cause a delay in the response. We had to daemonize as just fork()ing and exec()ing still left the parent process waiting before finishing the response. I didn't take the time to investigate why.

But testing showed that standard daemonization was sufficient. Note that we chose to exec() from the beginning as not exec()ing has risk of leaving objects alive that might cause problems, especially when the child finishes (and the objects try to finish their work).

We send the data needed for the finalization work as JSON written through a pipe to the child's STDIN: 

open( my $worker, '|-', $ASYNC_NOTIFIER ) or die ...;

[download]

And the child daemonizes after it finishes reading STDIN.

- tye        

Replies are listed 'Best First'.
Re^2: How to fork in PSGI/Dancer2 (daemonize)
by locked_user sundialsvc4 (Abbot) on Jan 30, 2015 at 22:10 UTC

    That sounds like a fine and practical solution.   The general problem with “daemonizing,” of course, is that the number of processes/threads will equal the number of active web requests, more or less.   If the number of requests is small, infrequent, etc., that’s all well and good.   But if the work to be done is “beefier” and there might be a large number of requests coming in to do such work, that’s specifically when I suggest that you should separate the two concerns.   Let the web strictly be a user-interface, to a separate workload-handling (background) activity which can be separately throttled.   Even if 1,000 requests to do some work, came in all at once, the system would still be able to apportion the work so that no more than some-n of those requests would be in-process at one time, on some number of servers.   The known worst-case completion times would not become “worse yet,” even though the waiting-lines might briefly have stretched out into the hallway.   The system would be briefly swamped, but not drowning.

    And none of this actually has any bearing on PSGI / FCGI / CGI / mod_perl or any other website implementation concern.

      That sounds like a fine and practical solution. The general problem with “daemonizing,” of course, is that the number of processes/threads will equal the number of active web requests, more or less

      Sure it isn't -- why would you daemonize for every request? That sounds like PEBKAC

[reply]

In Section Seekers of Perl Wisdom