Carl Worth wrote: > > A downside is that these new, inert objects are exposed to the > application and might cause unexpected side effects. (In practice, as > I've been switching various parts of cairo's internals to this scheme, > the worst side effect I've found is that switching to an inert-object > scheme defeats previous checks for NULL return values. In GTK+ that > problem shouldn't exist as nobody is checking for NULL return values > already).
Inert objects would only seem reasonable if your objects/operations are doing things that in some sense "can" be skipped; e.g. if you don't repaint a window, I guess that isn't catastrophic. (Though sending a mangled print job might be...) The memory pool thing IMO just doesn't work very well though; it's a probabilistic/one-time/race-prone hack pretty much. dbus goes further than both and "actually handles" OOM, i.e. all its functions are "transactional" and their effects roll back on OOM, so you can retry the operation if OOM is detected. I would not recommend this without 100% test coverage *including simulating failure of each and every malloc* - dbus has about 70% coverage, and when I added the coverage around 5% or so of mallocs were handled in a broken way, and fixing them required a number of API changes. So you will NOT get this right without extensive testing, though you might write a lot of code you think works and think you got it right and sleep at night, you would be mistaken ;-) As another proof, when I added malloc failure testing to libxml2 (which thought it had it right) for the first time, libxml2 blew up left and right. I think it might be fixed now. In both the dbus and libxml2 cases, it was quite possibly a waste since apps don't check or handle any of the OOM stuff anyway. Well, dbus-daemon is the only app that does, at least. For almost all apps I think gtk pretty much has this right already. Aborting (or perhaps sleep() and retry a few times) is all that makes sense. Remember there's g_try_malloc that apps can use for allocating large objects where failure is likely. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
