[Paraview] vtkSocket bugs

[David Partyka]

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>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> 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> 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> 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
>>>>
>>>> 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/20110414/a83e8192/attachment-0001.htm>