<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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">
https://github.com/hdima/erlport/blob/master/priv/python2/erlport/erlproto.py#L106-L110</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>
<br>
<br>
Thanks<br>
Khitai<br>
<br>
<blockquote cite="mid:5929D35A.5000704@gmail.com" type="cite">Best Regards,<br>
Michael<br>
</blockquote>
</body>
</html>