We're seeing hangs with multithreaded calls to Xft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here's the problem as described by a collegue.

  --David Hollingsworth

----------

We have a large, multithreaded program where each thread opens a
separate X11 Display.  We do not need per-Display locking, but we call
XInitThreads on startup to avoid corruption of certain global X11 data
structures.

Unfortunately, we still see occasional hangs in the Xft library.

The problem is that Xft maintains the global linked list
'_XftDisplayInfo', but always manipulates it without a lock in
xftdpy.c.

Not only does opening or closing a display manipulate the list, but
_XftDisplayInfoGet does an "MRU" operation to move an element to the
front of the list, so for a program like ours the race condition can
strike during numerous different Xft operations.

The bottom line is that we get occasional corruption of this linked
list where it becomes circular, causing the next thread who uses it to
spin forever.

_XftDisplayInfo (and similar global data structures, if any) needs to
be protected with a mutex.  For performance reasons it would obviously
be ideal, as in other X11 code, for locking to be a no-op unless
XInitThreads had been called.  If tying into XInitThreads is difficult
for some reason, there needs to at least be a special Xft proc that
enables locking analogously to XInitThreads.

Thanks!

-Mat

----------



[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux