On 9. Feb, 2007, at 9:51 , Robert Osfield wrote:

Hi Stefan,

On 2/9/07, Stefan Eilemann <[EMAIL PROTECTED]> wrote:
One window.

In the original test I was running singlethreaded. I've just tested
with all threading models from your 'osgviewer threading model control
and stats report' mail, and osgviewer always hangs in XLockDisplay.

At what point does it hang, still just on exit.

I've only tested the exit. The stack trace is the same as previously.


Just out ouf curiosity, do you need XInitThreads? In my experience,
as long as you use a Display* connection only from a single thread,
i.e., you open one connection per thread, XInitThreads is not needed.
In Equalizer and MPK I haven't needed it for >5 years.

osgViewer is polling events from the main loop, but potentially
rendering from another thread, so there are two threads using the same
Display connection.  I found that I needed XInitThreads to make things
work on my dual core, dual GPU system here.  I haven't noticed any
performance hit with using it.

There is no performance hit if you have very little Xlib calls like
osgviewer, but XInitThreads creates afaik a global lock.

If you are running single threaded then XInitThreads won't be required.

true.

Potentially we could run a separate thread to get the events and have
this thread with its own connection, like Producer does.  Producer has
had exit problems due this event thread, which haven't been easy to
resolve, so I'm hesitant to go down this route.

Understandable. Finding this issue was the point of the discussion
thread with Don. I haven't observed it, but most of the window closures
are handled using the WM_DELETE_WINDOW atom in Equalizer. Maybe I am
just lucky to use the DestroyNotify sparsely enough.

The other route would be to have separate Display connection for each
window for the main thread.  This might be the cleanest alternative
solution.

XInitThreads itself shouldn't be causing problems, but solving them...
so I wouldn't expect this to be a avenue to look for a solution.

I agree. I just digressed in this discussion because I think the second
connection is the cleaner approach. Note that you only need a event
connection per pipe (a.k.a. X11 screen), but grouping windows by pipe
might be difficult in osg.


Back to the XInitThreads/lock issue: Since it also happens in
singlethreaded mode, I suspect something fishy like memory
corruption or using a deleted resource. I see no other way
to deadlock on a mutex from a single thread, since it is
definitely not called recursively.


Cheers,

Stefan.
--
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to