<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Erik,<div><br><div><div>On 27 Sep 2012, at 13:37, Erik Søe Sørensen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">2012/9/27 Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>Hi Erik,</div><div class="im"><div><br></div><div>On 27 Sep 2012, at 03:20, Erik Søe Sørensen wrote:</div><blockquote type="cite"><p>It is the responsibility of the port program to shut down when stdin reaches EOF.<br>
This behaviour/expectation confused me too at some point, but it probably has its merits: not all software is designed for "let it crash", so simply killing the port program might be too crude in some circumstances.</p>
</blockquote></div>Well that's fine, but it should be documented a bit more clearly IMHO.</div></div></blockquote><div> </div><div>It's not in the API docs for open_port(), but in the section in the manual which definesports (<a href="http://www.erlang.org/doc/reference_manual/ports.html#id84207">http://www.erlang.org/doc/reference_manual/ports.html#id84207</a>) it does say<br><p style="margin-left:40px">The external program resides in another OS process. By default,
it should read from standard input (file descriptor 0) and write
to standard output (file descriptor 1). <i>The external program
should terminate when the port is closed.</i></p></div></div></blockquote><div><br></div><div>Ah yes, I see that now. I should've probably gone through that more carefully.</div><br><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> Also the port program, in this instance, is another beam emulator, so it's clearly *not* going to behave that way!</div>
</div></blockquote><div>Why not? - see below.<br></div><div>You could add<br>4. Ensure that the node runs a reading loop which detects EOF - e.g. using file:read_line(standard_io) or file:read(standard_io, SomeBlockSize).<br>
<br>Example for detecting EOF:<br>erl -noshell -eval 'F=fun(G)->X=file:read_line(standard_io), io:format("~p\n", [X]), X==eof orelse G(G) end, F(F), init:stop().'<br><br>You can even do exactly this in practise: put the loop code on the command line.<br>
<br></div></div></blockquote><div><br></div><div>This is excellent - I can actually provide that as a hook that can be set to run on each remote vm that is launched. Presumably this won't over-stress the io subsystem too much?</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Item 3 is the least preferable as it is not portable (relies on 'kill' being a shell built-in, etc) and requires that the os process id is known. It sounds like (2) is not a workable solution unless the external program is hand written to deal with 'stdin reaches EOF'. This is less than ideal, as it means that open_port/2 is not much use for spawning (and monitoring thereafter) arbitrary programs unless you're willing to live with the fact that you're not able to shut them down by closing the port. </div>
</div></blockquote></div><br>No, the port mechanism was apparently not meant for arbitrary slave programs. However, a little wrapping can often get you far, as Jesper demonstrated earlier.<br>
</blockquote><br></div><div>Yes, I'll probably look at both options to see which fits best. I'm actually finding launching and managing the vm via scripts quite cumbersome compared to using the slave module and a dose of rpc, but the primary goal is testing existing code and that code is normally launched and managed mainly via wrapper scripts, so it's probably the right thing to test them in the same way.</div><div> </div><div>Thanks again for your input, and I'll try to ponder the documentation a bit more carefully next time. I'm also more aware now of the constraint and will keep it in mind for the future.</div><div><br></div><div>Cheers!</div><div>Tim</div><br></div></body></html>