Humm, I forgot all about this email. I&#39;ll stick it in right now for 3.10.2. If you don&#39;t mind please file a bug so that it isn&#39;t forgotten.<br><br><div class="gmail_quote">On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring <span dir="ltr">&lt;<a href="mailto:bloring@lbl.gov">bloring@lbl.gov</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    Hi Dave,<br>
    <br>
    What is the status on this?<br><font color="#888888">
    <br>
    Burlen</font><div><div></div><div class="h5"><br>
    <br>
    On 02/27/2011 02:53 PM, David Partyka wrote:
    <blockquote type="cite">Thanks Burlen, We&#39;ll take a look.<br>
      <br>
      <div class="gmail_quote">On Sun, Feb 27, 2011 at 5:18 PM, Burlen
        Loring <span dir="ltr">&lt;<a href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
          Hi,<br>
          <br>
          While installing ParaView on Nautilus, <a href="http://www.nics.tennessee.edu/computing-resources/nautilus" target="_blank">http://www.nics.tennessee.edu/computing-resources/nautilus</a>,
          I hit a bug in vtkSocket that prevents ParaView from running
          on this machine. While tracking this down I uncovered a couple
          related issues.<br>
          <br>
          The main issue is that vtkSocket does not handle EINTR. EINTR
          occurs when a signal is caught by the application during a
          blocking socket call. While ParaView does not make use of
          signals they are used for asynchronous communication by some
          SGI specific libraries on Nautilus that are linked in with SGI
          MPI. Because Rank 0 pvserver spends quite a bit of its time
          blocked in socket calls it only takes a few 10s of seconds for
          EINTR to occur. When faced with EINTR ParaView silently exits
          leaving the user wondering what the heck happened. Which
          brings me to the second issue, a lack of error reporting in
          vtkSocket.<br>
          <br>
          To solve the first issue vtkSocket has to handle EINTR. How
          EINTR should be handled depends on the specific socket call.
          For all calls except connect the call can simply be restarted.
          For EINTR during connect one can&#39;t restart the call on all
          unix, so instead one must block in a select call when connect
          fails with EINTR. To be portable across Unix one should handle
          EINTR in all socket calls, even simple ones like
          set/getsockopt.<br>
          <br>
          The second issue of error reporting applies to all socket
          related errors in general, my feeling is that when a socket
          call fails vtkSocket should print a message using
          vtkErrorMacro, errno, and strerror(or windows equivalent) at
          the point of failure. I think this should be done inside
          vtkSocket because this is the only place one can safely assume
          errno has relevant information and vtkSocket has been
          implemented returning a single error code, -1, so that
          returning the real error code would change the API and break
          existing code, including ParaView. Not to mention that the
          values for error codes are apparently different on windows and
          unix.<br>
          <br>
          I took a stab at fixing these issues, patches attached. I
          tested them on my workstation, nautilus, and laptop running
          xp. I ran a dashboard on my linux workstation and didn&#39;t see
          any related issues. Would someone at KW mind taking a look at
          the changes and see if it could be made permanent?<br>
          <br>
          By the way after testing all socket calls for error returns I
          uncovered a third bug, vtkSocket::Close didn&#39;t set the
          descriptor ivar to -1 which resulted in vtkSocket::~vtkSocket
          calling close on a closed socket. Not a disasterous error, but
          this reinforces my opinion that the returns should be tested
          and error messages printed.<br>
          <br>
          Thanks<br>
          <font color="#888888">
            Burlen<br>
            <br>
            <br>
            <br>
            <br>
            <br>
            <br>
          </font><br>
          _______________________________________________<br>
          Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
          <br>
          Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
          <br>
          Please keep messages on-topic and check the ParaView Wiki at:
          <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
          <br>
          Follow this link to subscribe/unsubscribe:<br>
          <a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br>