Tracking whether a connection is alive
hp at redhat.com
Mon Jul 12 06:47:36 PDT 2004
I'd advise against a ping here. The basic problem (encountered with
metacity a fair bit also) is that it's a time-based heuristic. Which
The specific unreliability that happens most often e.g. in the window
manager context is that you can't tell the difference between slow/busy
and locked up. If you make the timeout really long (say, 1 minute or
even 30 seconds) then the user will start killing apps and rebooting
before the timeout expires; and if you make the timeout any shorter,
then you'll time out a lot of cases where nothing is really locked up.
Leases are generally used when you don't have a persistent connection
(e.g. using http for communication) and you want to GC server-side
resources from time to time. So you'd usually use a lease with quite a
long timeout, they aren't used to solve a user-visible problem, just to
avoid running out of resources on the server.
Anyhow, the service-tracking stuff was explicitly designed for this
"reliably know when the peer vanishes" use case.
I think it's fair to say that our desktop experience with IPC is "all
heuristics are categorically a bad idea" - they result in flaky errors,
race conditions, lingering unused processes, and so forth. Behavior
should all be deterministic, and then if there are bugs, we fix them
(and they will be reproducible).
More information about the dbus