[Haskell-beginners] forkProcess behaviour

Michael Snoyman michael at snoyman.com
Tue Jul 24 05:10:48 UTC 2018


On Fri, Jul 20, 2018 at 10:19 AM PICCA Frederic-Emmanuel <
frederic-emmanuel.picca at synchrotron-soleil.fr> wrote:

> > Hi Frederic,
>
> Hello Michael
>
> Thanks a lot for your informative answer.
>
> > Let me give a high level recommendation: don't use forkProcess. It's a
> very dangerous function, which can result in confusing behavior and
> impossible-to-debug problems. There are cases where it can be made to work,
> but (1) it's complicated, (2) I'm not sure anyone has ever figured out all
> of those caveats, and (3) it's certainly not documented properly.
>
> > forkProcess is little more than a call to the fork() system call,
> creating a brand new child process which will run the IO action provided.
> The runtimes of the two processes will not be > connected to each other at
> all. It would be impossible to, say, throw an exception from a thread in
> the parent process to a thread in the child process.
>
> > I could say a lot more about this, but I think I'll just reiterate my
> original recommendation: don't use forkProcess :)
>
> > Instead, for this kind of use case of changing user/group IDs, I'd
> recommend using a normal external process call via the process package[1].
> I'm not sure of your use case exactly, > but I see three ways of making
> this work:
>
> > * Generate two Haskell executables
> > * Put the code for both the parent and child into a single executable,
> and use command line arguments or env vars to control which behavior is run
> > * If you don't have any real logic in the Haskell code, and instead are
> just using some other program: you can call that directly
>
> I am quite close to this model, since I have only once executable and the
> command line parameters allows to execute the different job like this
>
> autoprocessing-exe [exec|submit|server] <jobname> parameters
>
> I start my service via the server command without parameters.
> Then from another computer, I can submit jobs to that server.
> And locally I can execute jobs with the exec command.
>
> What you proposed is just to execute the autoprocessing-command line with
> s/submit/exec in order to execute a child process.
>
> I think that I can do this.
>
> Now sometimes this process hang and I want to add a timeout, can I just
> use timeout for this purpose.
>
>
For the most part, yes. You may need to reach deeper and use SIGKILL
occasionally, depending on how stubborn the child process is. The `timeout`
will only kill off the parent thread's call to block on the child's exit
code.


> 2) I do not want to have communication between my server process and the
> child one, so in that case is it worth changing the code in order to use
> process instead of forkPRocess.
>
> With process I will need to had lot's of code in oder to convert my job
> type into command line.
>
> I have for now the right Parser command line -> jobtype, but not the other
> way around.
> This is why I used forkProcess et first.
>
> Once again thanks for your valuable comments.
>
>
Yes, you should avoid forkProcess in this case, it will have unpredictable
and confusing results.


> Frédéric
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20180724/12633e6e/attachment.html>


More information about the Beginners mailing list