[dancer-users] How can a fork+system() Dancer app not create zombie processes?
Andrew Beverley
andy at andybev.com
Mon Apr 3 12:21:36 BST 2017
On Mon, 3 Apr 2017 13:22:16 +0300 Shlomi Fish wrote:
> > Forking a web app is not as simple as it first seems.
>
> Do you mean forking any web app or just Dancer apps?
Yes, any web application, and probably any application that runs
continuously. The parent process needs to reap the child processes.
> > You need to take
> > an approach like the following (hopefully the comments will explain
> > without me regurgitating here, but feel free to ask for
> > clarification):
> >
> > https://github.com/ctrlo/GADS/blob/cb8c9478dee8eac1f40a44486634173bed8d666d/lib/GADS/Record.pm#L1068
> >
>
> I don't understand the code there in part because it uses too many
> custom APIs
As Racke says, you just need to use that concept. I.e. the parent
process forks a child; the child process terminates immediately after
it has spawned a grandchild, which allows the parent to reap the child.
The grandchild is then left hanging and becomes init's responsibility.
> like "guard"s
You should consider a guard, to ensure that nothing in the grandchild
causes it to hang around. For example, if there is an exception which
is then caught before the _exit(), you can end up with the grandchild
hanging around serving web requests to nobody ;-)
> and "try".
You can ignore that.
> Furthermore, the licence is the AGPLv3 which cannot be used inside my
> MIT Expat code.
IANAL, but I wouldn't say that small snippet of code is copywritable.
Nonetheless, I can speak with authority for Ctrl O, and you are welcome
to freely copy without condition that whole forking section if you want.
Andy
More information about the dancer-users
mailing list