<br><br><div class="gmail_quote">On Sun, Nov 23, 2008 at 11:57 AM, Per Hedeland <span dir="ltr"><<a href="mailto:per@hedeland.org">per@hedeland.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">"Edwin Fine" <<a href="mailto:erlang-questions_efine@usa.net">erlang-questions_efine@usa.net</a>> wrote:<br>
><br>
> One of the most annoying aspects is that under<br>
>circumstances that are not clear to me, the C program that is spawned<br>
>sometimes does not seem to be sent a signal for end of file when you close<br>
>the port, so if it is reading stdin, it's just going to sit there until<br>
>killed manually.<br>
<br>
</div>This should never happen - i.e. there is no "signal" for end of file,<br>
it's just the result of reading when there is nothing more to read - but<br>
a port program that actually reads its stdin should always get end of<br>
file when the port is closed (after having read what there is to read,<br>
if anything). "You're probably doing something wrong."</blockquote><div><br>You're probably right. But nothing wrong in the C program, I don't think. That's why I found it a bit frustrating to get the Erlang program working correctly.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> Worse, if it gets stuck doing something and is NOT reading<br>
>stdin then you are out of luck.<br>
<br>
</div>This is expected, and can be considered a feature - it allows you to<br>
e.g. start a daemon that *should* keep running after you close the port.<br>
<div class="Ih2E3d"></div></blockquote><div><br>There are well-known techniques to starting daemons that don't rely on open ports (e.g. fork a child, close all open files, fork another child, trap signals, open stdin/out etc). So I am not sure this such is a good feature because it makes it difficult to kill misbehaving OS programs that were spawned by Erlang.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
>But what if the 'C' program is not under your control, say, it's part of<br>
>Linux, and you need to make sure it's killed when you are done? Then I<br>
>believe you need to write a wrapper around the 'C' program. I refer you to<br>
>the following post for an interesting way to do this:<br>
><br>
><a href="http://www.erlang.org/pipermail/erlang-questions/2007-October/030377.html" target="_blank">http://www.erlang.org/pipermail/erlang-questions/2007-October/030377.html</a><br>
<br>
</div>It may be "interesting":-), but I wouldn't really recommend that you use<br>
that "code", it was kind of a "I bet it can be done" thing, in<br>
particular implementing {packet, 2} protocol in 'awk' is not exactly<br>
ideal.:-) 2-3 lines of readable C code would be a better idea.<br>
<font color="#888888"></font></blockquote><div><br>I understand - I was pointing more to the idea than the implementation. I think Erlang/OTP should perhaps provide a standard wrapper C program that will run any program as a child, and has a back-channel that allows you to kill it (and its child) if the child becomes non-responsive.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
--Per Hedeland<br>
<br>
</font></blockquote></div>Edwin Fine<br>