Re: Some comments about GVFS



On Fri, 04 May 2007 10:27:34 -0400, Havoc Pennington wrote:
> It's a run-time env variable. I think we don't advertise it at all, it's
> more of a defense against people who have strong views on the topic and
> prefer "undefined behavior probably a crash" to "just exit" ...

And one thing to note here is that cairo does provide an additional
option:

	"No behavior, will not crash"

which I think can form a good compromise between the camps that prefer
each of the options you mention. (Though I'll agree that debugging
would be easier if cairo _also_ provided a run-time mechanism to get
the "just exit" along with an error message giving as much context as
possible for the time of the error.)

The point is, while it might not make sense to talk about error
recovery from any single low-level library operation, (see your
"failed to draw a rectangle" example), applications still will very
much want to have high-level behavior of "something has gone very
wrong, let's save the user's important state before exiting".

There are a few things a library could do that would defeat that
almost entirely:

1. Exit

2. Start doing undefined things

3. Require error-checks on every call into the library to prevent it
   from doing undefined things

You seem to be saying that it's impractical for a library to avoid 2
or 3, so there's no reason not to do 1. But I think with cairo we've
got a practical approach for getting close enough to avoiding all
three so that applications really can do high-level error recovery.

And that seems useful.

> When I first implemented this it found quite a few bugs, I then
> implemented something similar for part of libxml and also found a lot,
> so that's why my party line since has been that trying to handle OOM
> without testing the OOM codepaths is more hopeful fantasy than anything
> else.

I absolutely agree that testing is essential, and out-of-memory
handling is doomed without it.

And now that we've fixed so much in cairo, we really want to go fix
underlying libraries like fontconfig and freetype or else it's really
all in vain.

> (it's just too hard to get right without testing - in some cases
> in dbus-daemon I had to implement fairly complex "transactions" that
> could be rolled back, in other cases I had to change the library API to
> allow e.g. callbacks to signal OOM)

When we started testing cairo, we found several mistakes, (though
fewer than I had anticipated to tell the truth). But we've had nothing
come even close to needing any API changes. Part of that is certainly
due to cairo's problem domain where there aren't a lot of complex
interactions between separate operations, (can anyone imagine
transactions being useful when drawing?).

But another part comes from just accepting support for OOM-error-
handling as an upfront design constraint, rather than hoping to bolt
it on later.

-Carl

Attachment: pgp8GS4UtNkFt.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]