Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org
You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. Re: forkProcess behaviour (Michael Snoyman) 2. Re: forkProcess behaviour (PICCA Frederic-Emmanuel) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Jul 2018 08:10:48 +0300 From: Michael Snoyman <mich...@snoyman.com> To: Beginners <beginners@haskell.org> Subject: Re: [Haskell-beginners] forkProcess behaviour Message-ID: <cakt9ecmacbkn9sa+xjt++r5uoucanocb4dd7wuywgjeusge...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Fri, Jul 20, 2018 at 10:19 AM PICCA Frederic-Emmanuel < frederic-emmanuel.pi...@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@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-0001.html> ------------------------------ Message: 2 Date: Tue, 24 Jul 2018 07:05:18 +0000 From: PICCA Frederic-Emmanuel <frederic-emmanuel.pi...@synchrotron-soleil.fr> To: "The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell" <beginners@haskell.org> Subject: Re: [Haskell-beginners] forkProcess behaviour Message-ID: <a2a20ec3b8560d408356cac2fc148e530107e2d...@sun-dag4.synchrotron-soleil.fr> Content-Type: text/plain; charset="iso-8859-1" Hello I have done the first solution and call the program changing the command line in oder to execute each child task. It works well and I can change the uid gid of these process. > 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. Since all these tasks are executing also child process via other system cals. So I have a hyerarchy of process. Do you know how to manage that sort of things if something goes wrong and I need to kill the first child and all its children's ? Is it possible for CreateProcess to track all these process and kill them all on request ? > Yes, you should avoid forkProcess in this case, it will have unpredictable > and confusing results. I take you advices seriously and now I start to build something (I hope) more robust. Thansk Frédéric ------------------------------ Subject: Digest Footer _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners ------------------------------ End of Beginners Digest, Vol 121, Issue 19 ******************************************