Tracking whether a connection is alive
david at fubar.dk
Mon Jul 12 01:44:10 PDT 2004
On Mon, Jul 12, 2004 at 08:32:00AM +0200, Owen Fraser-Green wrote:
> 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
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