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