[patch] break glib bindings by adding timeout_milliseconds
david at fubar.dk
Wed Mar 1 08:38:03 PST 2006
On Wed, 2006-03-01 at 14:04 +0000, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2006 at 01:50:23AM -0500, David Zeuthen wrote:
> > On Wed, 2006-03-01 at 00:31 -0500, Havoc Pennington wrote:
> > Also note that we'll be adding more methods in HAL in the future that
> > potentially could easily take > 5 minutes to complete... such as methods
> > for formatting hard disks (a side effect of this method call is that it
> > will emit signals for progress, e.g. percentage complete for format
> > etc.).
> If it is going to emit progress signals, then what's the point in blocking
> on the 'FormatDisk()' method call? You might as well just return immediately
> and the client app can listen out for a 'completion' signal - which its going
> to be listening for anyway to display progress.
Because what if FormatDisk() fails just before completion because of bad
sectors and we want to throw the BadDiskSectorEncountered exception?
The point is really that if we do silly things like emitting signals for
completion / "errors" then the application developer has two paths he
needs to handle errors in:
1. When invoking the method the caller might get e.g. PermissionDenied
2. Other errors only detected while well into handling the method,
e.g. when we find that e.g. the disk has bad sectors or is broken.
That's just confusing. And I've not yet seen any good arguments for not
allowing methods to take forever to execute...
More information about the dbus