Tracking whether a connection is alive

David Zeuthen david at
Mon Jul 12 01:44:10 PDT 2004

On Mon, Jul 12, 2004 at 08:32:00AM +0200, Owen Fraser-Green wrote:
> Hi,
> On Mon, 2004-07-12 at 00:54, David Zeuthen wrote:
> > On Sun, 2004-07-11 at 23:46 +0100, Mike Hearn wrote:
> > > What I'd suggest is that while a peer has a device locked HAL sends Ping
> > > messages to that service every few seconds until it's unlocked. One
> > > downside is that by requiring this I guess you make it harder to write
> > > clients because if the task you're doing isn't easily interruptable (is CD
> > > writing? I guess it must be ....) you need threading and such to respond
> > > to pings.
> > > 
> > 
> > OK, any reasonable CD writer application probably has a thread to update
> > the UI anyway, so this seems like an acceptable thing to do.
> But this would only help to prove that the thread handling UI is alive
> and well but nothing much about the thread doing the actual job which
> owns the lock. What if that thread gets into an infinite loop or the
> library it calls locks up? If you then decide to make monitoring thread
> intelligent enough to detect these situations then it might as well have
> have just told HAL when the thread went AWOL instead of HAL polling it
> all the time.
> I don't think anything can really detect locking up better than the
> user...

Mmm, okay. So your point is that detecting and killing buggy
applications should better be left to e.g. the WM. Makes sense to
me. And then I don't have to ping, which makes my life a bit easier.


More information about the dbus mailing list