Xprt does not play well with D-BUS

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

 



Currently Xprt spins at 95% cpu usage (code from master or xserver 1.4).Xprt from xserver 1.3 was still behaving OK.
Xprt seems to be spinning in the dispatch() loop in dix/dispatch.c.  Asfar as I can tell, WaitForSomething() is returning too quickly, notwaiting in the expected manner.
The problem disappears when dbus is disabled (--disable-dbus).   Ipresume dbus events must be triggering off WaitForSomething().
That means the bug came in with the input-hotplug developments, whichlanded in xserver 1.4.  I've traced the problem at least as far back ascommit cf7ca9d09cba14d107152a5179de38e5ef7bd784 (24 Jan 2007), but hadtrouble testing further back due to other build problems.
As far as I'm aware Xprint has no actual need for dbus. At least, it'snot doing anything with it at the moment. NewInputDeviceRequest( ) andother functions in xprint/ddxInit.c are just dummy functions (perhapsdbus could be leveraged to instruct Xprint to update its list ofprinters, but that's not being done at the moment).
I can see two alternate workarounds, both simple and both emulating thedisabling of dbus within Xprint.
1) add dummy functions config_init() and config_fini() toxprint/ddxInit.c and remove CONFIG_LIB  from XPRINT_LIBS inconfigure.ac. Then I think the Xprt build will ignore dbus (so long asit never accesses XORG_CORE_LIBS).
This is consistent with other Input changes to xprint/ddxInit.c (otherdummy functions are already placed there).
2)  Use#ifndef XPRINT	config_init()#endifat l.298 of dix/main.c, and similarly for config_fini() at l.452.
Since a separate libdix (libXpdix.a) is already built for Xprt thanksto commit 966ae1781f3ca563e15a9a1b8cab6fab94e07fe9, this will have theeffect of disabling dbus for Xprint only.


Please give me feedback on which alternative patch you would prefer, or letme know if there is a better approach still.  I'm cc:ing Daniel as thechief author of the input-hotplug changes, in case he knows of a betterway of fixing the Xprt 95% cpu usage.
Drew

p.s. dmx seems to have been having similar build problems as xprintover the last year or so. I'm not sure if similar code adjustments needto be made for dmx as well, as I don't use Xdmx._______________________________________________xorg mailing listxorg@xxxxxxxxxxxxxxxxxxxxxxxxx://lists.freedesktop.org/mailman/listinfo/xorg


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [Intel Graphics]     [AMD Graphics]     [Nouveau Driver]     [XFree86]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Video for Linux]     [Linux RAID]

  Powered by Linux