[ pyopengl-Bugs-3127034 ] VBO deletion happening in another thread than Main thread

Bugs item #3127034, was opened at 2010-12-03 19:00
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: VBO deletion happening in another thread than Main thread 

Initial Comment:
Hi pyopengl dudes,

I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault.

I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py.
And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...)
And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)>

Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/

It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread.

Do you confirm this case ? Do you have any tips about how to do ?
I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...)

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-06 09:21

Message:
?? boggle ??  Okay, *that* is surprising.  AFAIK the weakref code is just
hooked into the DECREF counting so that iff count goes to < 1 then the
weakrefs are called, then the __del__ method.  I suppose somehow one of the
callbacks might allow a thread context switch... but that still seems
pretty exotic.  Don't suppose you have a small test-case that shows this?

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2010-12-05 12:11

Message:
Just to ensure you've understand me, i don't do any deletion of VBO in
another thread than main thread. I've a reference to the VBO in a class,
and when the class is gone, the vbo is gone too. All theses operations are
always executed in a main thread.

That's why i think this bug can happen as soon as you use thread in python
no ? And that's problematic :/

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-05 08:49

Message:
The appropriate way to delete a VBO in a multi-threaded situation is to
call .delete() on it in the rendering thread *before* you delete the VBO in
another thread.  The VBO's cleanup will then *not* delete the VBO. 
Anything I do to try to work around this will constrain the design of all
pyopengl applications.

That said, your approach would work fine (moving the deletions to the main
thread) for your application:

# non-render thread
for obj in objs_to_delete:
    remove_from_tree(obj)
    to_delete_queue.push( obj ) # no garbage collection here because of
this reference

# render thread
while: to_delete_queue:
    to_delete_queue.pop() # garbage collected and deleted here...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net