<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/27/2017 01:35 PM, Khitai Pang
wrote:<br>
</div>
<blockquote
cite="mid:KL1PR0601MB1941F94AF2F8F0CA58B7A827FCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
On 2017/5/28 03:28, Michael Truog wrote:<br>
<blockquote cite="mid:5929D35A.5000704@gmail.com" type="cite">
<div class="moz-cite-prefix">On 05/27/2017 12:06 PM, Khitai Pang
wrote:<br>
</div>
<blockquote
cite="mid:KL1PR0601MB19412A3CAA9D13EFBDEC039FFCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
On 2017/5/28 01:45, Michael Truog wrote:<br>
<blockquote cite="mid:5929BB28.5010008@gmail.com" type="cite">
<div class="moz-cite-prefix">On 05/27/2017 09:21 AM, Khitai
Pang wrote:<br>
</div>
<blockquote
cite="mid:KL1PR0601MB1941A53760411CFD2C052A84FCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
On 2017/5/28 00:06, Michael Truog wrote:<br>
<blockquote cite="mid:5929A400.9060204@gmail.com"
type="cite"><br>
On 2017/5/27 23:31, Khitai Pang wrote: <br>
<blockquote type="cite">
<blockquote type="cite">I have observed a situation
where the port process exits with reason
<br>
'einval' but the external program still runs. The
connected process of <br>
the port receives
{EXIT,#Port<0.3069817>,einval}. What makes a
port <br>
process exit with 'einval' while the external
program still runs? <br>
</blockquote>
</blockquote>
<br>
Normally that is due to the port source code</blockquote>
<br>
Do you mean the source code of the external program?<br>
</blockquote>
<br>
Yes<br>
<br>
<blockquote
cite="mid:KL1PR0601MB1941A53760411CFD2C052A84FCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
<br>
<blockquote cite="mid:5929A400.9060204@gmail.com"
type="cite">not handling a HUP on the output file
descriptor,from poll (POLLHUP) or the equivalent using a
different function.<br>
</blockquote>
<br>
Could you be more specific about this situation? In what
occasions will this happen?<br>
<br>
My external program is a python script that uses <a
moz-do-not-send="true"
href="https://pypi.python.org/pypi/erlport">
erlport</a> to communicate with erlang.<br>
</blockquote>
<br>
erlport should be getting EPIPE in the source code <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/hdima/erlport/blob/master/priv/python2/erlport/erlproto.py#L106-L110"><a class="moz-txt-link-freetext" href="https://github.com/hdima/erlport/blob/master/priv/python2/erlport/erlproto.py#L106-L110">https://github.com/hdima/erlport/blob/master/priv/python2/erlport/erlproto.py#L106-L110</a></a>
. However, that depends on the write function getting
called to discover the Erlang VM disappeared.<br>
</blockquote>
<br>
Thank you for your explanation, but I don't really understand,
if the cause is that the Erlang VM certainly disappeared, how
come the connected process got the
{EXIT,#Port<0....>,einval} message?<br>
</blockquote>
That message is the Erlang message inside the Erlang VM related
to the Erlang port type used for the pipes that were used for
the erlport executable. So, that means the Erlang port type
died with a posix einval error, but that doesn't mean that the
erlport executable is aware of a problem. It is possible the
error is only seen by the Erlang VM if the erlport has no reason
to call the write function, mentioned above.<br>
</blockquote>
<br>
Hi Michael,<br>
<br>
OK I see what you mean, the external program process doesn't know
that its Erlang port process has exited, because it hasn't written
anything to the output file descriptor after that. I think you
are right about this.<br>
<br>
<blockquote cite="mid:5929D35A.5000704@gmail.com" type="cite">
<blockquote
cite="mid:KL1PR0601MB19412A3CAA9D13EFBDEC039FFCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
Anyway, what to do to avoid this issue?<br>
</blockquote>
Not sure, it may require changing erlport or taking a different
approach. To avoid the problem, you could attempt to always
make the erlport executable exit by executing "sys.exit(0)" or
something similar, but that isn't dependable when you are unable
to send erlport something to exit (i.e., if a sudden error makes
the Erlang port type unusable in the Erlang VM, as appears to
have happened here).<br>
</blockquote>
<br>
When the Erlang port process is gone, I don't think the Erlang VM
can send anything to the external program process. However, I
think we still have a way to kill the external program process:
after creating a port, use erlang:port_info(Port, os_pid) to get
the OS pid of the external program process and save it somewhere,
e.g. in gen_server state. When the Erlang port process dies, kill
the external program process by its OS pid. I haven't tested it,
though.<br>
<br>
Actually, in my case, it's not a serious problem that the external
program process is not aware of the exiting of its Erlang port
process and keeps running after that. What I'm really concerned
with is why the Erlang port process died with einval error, this
is a serious problem and I need to find a way to fix it. Any
idea?<br>
</blockquote>
<br>
Based on <a class="moz-txt-link-freetext" href="http://erlang.org/doc/man/erlang.html#open_port-2">http://erlang.org/doc/man/erlang.html#open_port-2</a>
documentation "<span class="code">einval</span> if no POSIX code is
appropriate", einval is not the normal POSIX error from exec. If
the port executable is still running, then perhaps it
unintentionally closed the pipes the Erlang VM is trying to use
(since that doesn't appear to be mentioned in any of the other POSIX
errors). That may have happened after a python exception possibly,
but this is something you would need to explore.<br>
<br>
Best Regards,<br>
Michael<br>
</body>
</html>