[erlang-questions] managing OS processes
Robert Raschke
rtrlists@REDACTED
Tue May 29 13:13:16 CEST 2012
On Tue, May 29, 2012 at 10:21 AM, Ciprian Dorin Craciun <
ciprian.craciun@REDACTED> wrote:
> Hello all!
>
> I don't think its the right way (although it seems to be suggested
> by the Erlang manual or somewhere else I've read it), but the way I
> did it was to write a small C program that is the one "babysitting"
> the real process, and a small Erlang wrapper.
>
> The code is here (Apache 2.0 licensed):
>
> https://github.com/cipriancraciun/mosaic-node/tree/development/applications/mosaic-harness/sources
>
> https://github.com/cipriancraciun/mosaic-node/blob/development/applications/mosaic-harness/sources/mosaic_harness_backend.erl
>
> https://github.com/cipriancraciun/mosaic-node/blob/development/applications/mosaic-harness/sources/mosaic_harness.c
>
> The C program allows the following:
> * it uses a small protocol based on JSON to communicate with the
> Erlang wrapper, using solely `stdin` / `stdout` between itself and
> Erlang, and between itself and the "babysitted" program;
> * it allows a single process to be executed at a time (controlling
> environment, arguments, and working directory); (it could be extended
> to multiple process in parallel if wanted;) (but you can run it again
> if you want;)
> * it allows a signal to be sent;
> * it allows "exchange" messages to be sent to and from Erlang and
> the process;
> * it allows brutal termination; (i.e. SIGKILL;)
> * if `stdin` is closed by the Erlang side it kills the process;
> * if `stdin` is closed by the process side it informs the Erlang side;
>
> The C part is a self-contained `.c` file (of about 2k lines, of
> which 25% are structure definitions), written in an event driven
> manner (no threads), statically linkable, depending only on the
> `jansson` library (for JSON), using mostly POSIX syscalls.
>
> I've successfully used it for about a year now (in non-production
> systems) and it behaves nicely.
>
> If someone finds it useful I could try to extract it in a
> standalone project.
>
> Ciprian.
>
>
I have a similar "proxy" to run killable external programs on Windows. It's
part of a larger project though, so I'd need to extract it. Would there be
interest for me to do that?
The approach is:
Start the proxy program using open_port/2 and send it the command to run,
the proxy then uses DuplicateHandle() and CreateProcessW() to kick off the
command in a separate OS process but with stdin/stdout/stderr forwarded
from the proxy to the new external command, prints the OS process id back
to Erlang and waits for the external OS process to finish.
Thus you now have your command running in the backgroud, able to
communicate using stdio with the Erlang process that started the proxy.
If you want to stop the command, you invoke the proxy with the process id
you got earlier and it kills it using TerminateProcess().
Robby
PS I vaguely remember getting the idea of passing back a process id for
later kill purposes from some open source app that uses a similar approach
to running killable commands from Erlang. Not that I can remember which one
at the mooment, sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120529/7ed08f29/attachment.htm>
More information about the erlang-questions
mailing list