[Paraview] vtkSocket bugs

[Burlen Loring]

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.partyka at kitware.com <mailto:david.partyka at kitware.com>> wrote:
>
>     Thanks Burlen, This is applied for 3.10.2.
>
>
>     On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <bloring at lbl.gov
>     <mailto:bloring at 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
>>         <bloring at lbl.gov <mailto:bloring at 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
>>>             <bloring at lbl.gov <mailto:bloring at 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
>>>
>>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110415/e3d188e9/attachment-0001.htm>