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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
