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
******************************************

Reply via email to