[vtkusers] Problems with vtkFlRenderWindowInteractor

[Jeff Lee]

Robert Belleman wrote:

>On Thu, Oct 31, 2002 at 06:27:24AM -0500, Jeff Lee wrote:
>  
>
>>Robert Belleman wrote:
>>    
>>
>>>On Wed, Oct 30, 2002 at 04:14:41PM -0500, Joshua A Foster wrote:
>>>      
>>>
>>>>1) We are all running NVidia drivers version 1.0-3123 now, and we still get 
>>>>"XRequest.144: BadAccess (attempt to access private resource denied)" 
>>>>frequently and "Xlib: unexpected async reply (sequence 0xa9)" on rare 
>>>>occasions.
>>>>        
>>>>
>>>You will get the latter message when multiple threads access the same
>>>X server.  To solve this, call XInitThreads() at the start of your
>>>program.
>>>
>>>Actually; this issue has come up a number of times now, so it warrants
>>>a permanent solution.  It would be a good idea to add this call to
>>>vtkXOpenGLRenderWindow.cxx.
>>>
>>>      
>>>
>>IMHO, this would not be a good place to make this call, as it must be 
>>called before any other X calls,
>>    
>>
>
>You're right; XInitThreads should be called before any other X call. 
>
>  
>
>>and there are very few situations I can 
>>think of where a vtkXOpenGLRenderWindow is the first X-related object 
>>created in an app.
>>    
>>
>
>Well... Most C++ examples in the Vtk source tree will probably call
>XOpenDisplay() in vtkXOpenGLRenderWindow as their first X call, but
>granted; non of these are multi-threaded and so they will not suffer
>from this problem.
>
>Anyway; now that I've given it a little more thought -
>vtkXOpenGLRenderWindow is, indeed, probably not the right place.
>
>  
>
>>Another solution is to make the call from your own program,
>>    
>>
>
>Agreed; we should add a note about this in the FAQ.
>
>But I think there is a little bit more we could do;
>
>I noticed that some of the Vtk interfaces to X windows GUI toolkits
>(i.e. Qt, Fltk, etc) use a multithreaded approach to split Vtk's and
>the toolkit's event handling loop - these interfaces should call
>XInitThreads at initialization.
>  
>
Yes, this is a better place to handle the problem.

>  
>
>>or better-yet to make sure that you only modify the render 
>>window from a single thread.
>>    
>>
>
>You mean; make sure that you only access *the X server* from one
>thread. The renderer is not the real issue.  However, there are
>advantages to multithreading an application *and* have the different
>threads access the same server.  One such example is a Vtk application
>in conjunction with an X GUI.
>
Yes, my comment was vague.  The renderer is not the issue, but the 
render window is (specifically vtkXOpenGLRenderWindow, 
vtkXOpenGLTextMapper).  These classes make glx calls, and are pretty 
much the only entrance points into X from VTK.  My suggestion to make 
sure that methods like Render() (or any other method resulting in a glx 
call) be called from a single thread is one solution, although 
admittedly broad-brushed.  This solution works well for Java 
(disturbingly multithreaded), where XInitThreads cannot be called before 
the jvm initializes X.  As stated above, the gui-toolkits are the place 
to take care of X thread safety.  I don't have alot of faith in 
XInitThreads (seems like a black box, not a robust solution), but I know 
that mutual exclusion locking works fine.
-Jeff

>
>-- Rob
>
>  
>