Bug#470901: xserver-xorg-core: Uses sync dbus calls through the libhal API

[Sjoerd Simons <sjoerd@luon.net>]

On Mon, Aug 25, 2008 at 08:12:33PM +0200, Julien Cristau wrote:
> (for some reason i never saw this report..)
> 
> On Fri, Mar 14, 2008 at 13:01:42 +0100, Sjoerd Simons wrote:
> 
> >  I just had a quite nasty experience. When running hal in verbose mode
> >  in a x terminal it locks up my X, untill i kill hald from another
> >  machine..  Stracing of X shows that it was blocking on dbus calls.
> >  What seems to happen is that hal's stdout/stderr buffers are filled
> >  up because X is busy with other stuff, causing hal to block, which in
> >  turn causes X to block when it calls out to hal the next time :(
> > 
> >  A quick look in the xorg-server code shows it's using libhal_*
> >  functions.  Almost all of these result in synchronous dbus calls
> >  (thus they block untill a reply is received). Which make them
> >  unsuitable for something as critical as the X server.
> > 
> >  From my point of view it might be best to turn the input hotplugging
> >  code in unstable for now as it's not actually used at this point
> >  anyway...
> > 
> >From my point of view it wouldn't be a good solution :)
> (we use the input hotplugging code to load the synaptics driver on
> laptops with touchpads, if nothing else, and will use it for most
> everything post-lenny)

Ah, i didn't know it was used for synaptics already.

> Is there any better way to fix this, or should we just consider it a
> wontfix thing?

Yes, patch the X server to not use synchronous dbus calls, which are definately
the wrong thing for it. This does mean the server should use dbus-glib or
libdbus directly (or fix libhal to expose async variants..).

It's definately something upstream should fix imho.

  Sjoerd
-- 
Genetics explains why you look like your father, and if you don't, why
you should.