Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. sorry about that, I'll have to try again.

Burlen

On 04/14/2011 07:54 PM, David Partyka wrote:
Hi Burlen, I had to revert your patch as it doesn't compile on Windows..

You will have to make sure it compiles there as well and resubmit your patch. If you need any help please let me know. Thanks.

On Thu, Apr 14, 2011 at 3:51 PM, David Partyka <david.part...@kitware.com <mailto:david.part...@kitware.com>> wrote:

    Thanks Burlen, This is applied for 3.10.2.


    On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <blor...@lbl.gov
    <mailto:blor...@lbl.gov>> wrote:

        Thanks Dave,

        Filed the bug report http://www.paraview.org/Bug/view.php?id=12087

        I updated the patch for 3.10.0 as well (attached here and on
        the bug report).

        Burlen


        On 04/13/2011 11:24 AM, David Partyka wrote:
        Humm, I forgot all about this email. I'll stick it in right
        now for 3.10.2. If you don't mind please file a bug so that
        it isn't forgotten.

        On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring
        <blor...@lbl.gov <mailto:blor...@lbl.gov>> wrote:

            Hi Dave,

            What is the status on this?

            Burlen


            On 02/27/2011 02:53 PM, David Partyka wrote:
            Thanks Burlen, We'll take a look.

            On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring
            <blor...@lbl.gov <mailto:blor...@lbl.gov>> wrote:

                Hi,

                While installing ParaView on Nautilus,
                http://www.nics.tennessee.edu/computing-resources/nautilus,
                I hit a bug in vtkSocket that prevents ParaView from
                running on this machine. While tracking this down I
                uncovered a couple related issues.

                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.

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

                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.

                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't see any related issues. Would
                someone at KW mind taking a look at the changes and
                see if it could be made permanent?

                By the way after testing all socket calls for error
                returns I uncovered a third bug, vtkSocket::Close
                didn'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.

                Thanks
                Burlen







                _______________________________________________
                Powered by www.kitware.com <http://www.kitware.com>

                Visit other Kitware open-source projects at
                http://www.kitware.com/opensource/opensource.html

                Please keep messages on-topic and check the ParaView
                Wiki at: http://paraview.org/Wiki/ParaView

                Follow this link to subscribe/unsubscribe:
                http://www.paraview.org/mailman/listinfo/paraview








_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Reply via email to