[erlang-questions] managing OS processes
Tue May 29 14:38:56 CEST 2012
This stuff is really good. But fundamentally, we're still in the world where the limitations of open_port are what dominates. Dave Smith's sh modules/functions for both rebar and retest handle this kind of proxy approach just fine, simply by using `sh -C 'echo $$; exec ' ++ Cmd` and using port io. Admittedly it doesn't support signal handling as cleanly.
I hear (on twitter) that there are improvements to port communication coming in R16, and I dearly hope that native processes will be with us by then. At that time, these issues *might* just go away, although they might not.
The other problem I run into is, what about daemon/detached scripts, things launched using setsid/nohup and/or put straight into the background? And how is your proxy program going to exhibit characteristics any different in this situation, where you cannot 'spawn' a sub-process (or whatever the windows equivalent is).
Anyway, despite my reticence, I think your programs both sounds pretty useful - although I'm bemused that you'd use JSON serialization instead of simply using the ei interface - and I would also suggest that packaging them as separate libraries would be very useful to the community, giving others the benefit of utilising your work!
On 29 May 2012, at 12:13, Robert Raschke wrote:
> 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):
> 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.
> 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().
> 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.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions