<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 12:06 PM, Khitai Pang
wrote:<br>
</div>
<blockquote
cite="mid:KL1PR0601MB19412A3CAA9D13EFBDEC039FFCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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
cite="mid:KL1PR0601MB19412A3CAA9D13EFBDEC039FFCFD0@KL1PR0601MB1941.apcprd06.prod.outlook.com"
type="cite">
<br>
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>
<br>
Best Regards,<br>
Michael<br>
</body>
</html>