libpulse use of Xlib is not thread-safe

[courmisch]

As specified by the Xlib documentation, XInitThreads() must be invoked before any other Xlib call in a multi-thread program. Alternatively, all Xlib calls shall be protected by some synchronization mechanism, such as a global Xlib use lock.

libpulse uses Xlib but does not call XInitThreads(). This compromises the thread-safety of any process using libpulse in the likely case that Xlib is also used from another thread. This is qutie common for multimedia frameworks with the audio pipeline in one thread and the video pipeline in another.

Unfortunately, I cannot find an easy fix for this issue. libpulse should probably not call XInitThreads(). This would cause problems in a non-threaded program that initializes Xlib before libpulse. Then libpulse would call XInitThreads() while Xlib is already initialized in non-threaded mode, which is invalid.

Since libpulse does a fairly minimal use of X11, using XCB instead of Xlib might be a more reasonable option. That would get rid of the problem.

[coling]

XCB conversion for libpulse (some server side modules still use Xlib)

[coling]

This is a patch against 0.9.21 stable-queue branch that converts Xlib calls to xcb calls for property getting/setting.

Some uses of XLib remain in the server side, but these wont bother a client application.

I've not tested this heavily yet, but it seems to be working as expected so far.

This patch does NOT apply cleanly on master as it conflicts with 65e8078a3bba6360f7918b2a721510d78826eece however, I'm not sure this matters anymore and I think the bits of code that cause the conflicts can be thrown out now.

Anyway, that's enough XCB'ing from me for now :)

[utumno]

The point of 65e8078a3bba6360f7918b2a721510d78826eece is to apply X11 properties to the root window of whatever is the current screen, rather than always to the root window of screen 0 as it used to be in 0.9.21.

This way, one can have different SINKs, SOURCEs, etc on all screens, which means that if one has a multi-screen setup, suddenly it is possible - by loading multiple 'module-x11-publish' this way:

load-module module-x11-publish display=":0.0" sink=foo load-module module-x11-publish display=":0.1" sink=bar

to achieve a setup where sound is automatically routed to different soundcards depending on on which monitor one is working on. Practical usercase given in:

http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg05045.html

I'll try and modify your patch.