Thanks Burlen, This is applied for 3.10.2. On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> >> >> > >
_______________________________________________ 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
