[erlang-questions] can a program launched with open_port({spawn, Cmd}, Options) remain running after the port closes?

[Tim Watson]

Hi Erik,

On 27 Sep 2012, at 13:37, Erik Søe Sørensen wrote:

> 2012/9/27 Tim Watson <watson.timothy@REDACTED>
> Hi Erik,
> 
> On 27 Sep 2012, at 03:20, Erik Søe Sørensen wrote:
>> It is the responsibility of the port program to shut down when stdin reaches EOF.
>> 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.
>> 
> Well that's fine, but it should be documented a bit more clearly IMHO.
>  
> It's not in the API docs for open_port(), but in the section in the manual which definesports (http://www.erlang.org/doc/reference_manual/ports.html#id84207) it does say
> 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). The external program should terminate when the port is closed.
> 

Ah yes, I see that now. I should've probably gone through that more carefully.

>  
> Also the port program, in this instance, is another beam emulator, so it's clearly *not* going to behave that way!
> Why not? - see below.
> You could add
> 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).
> 
> Example for detecting EOF:
> 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().'
> 
> You can even do exactly this in practise: put the loop code on the command line.
>  

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?

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

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

Cheers!
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120927/1ba3e1ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120927/1ba3e1ce/attachment.bin>