What is the policy on out-of-memory?

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Jan 13 03:57:11 PST 2009


On Mon, 12 Jan 2009 at 22:43:58 -0500, Havoc Pennington wrote:
> I should point out, the OOM handling in libdbus is primarily for the
> benefit of dbus-daemon. I don't know of a single app that's handling
> OOM properly even in theory; there may be some, but I'm skeptical they
> work in practice, at least for GUI apps. Most apps use dbus-glib and
> dbus-glib just applies glib's policy of exiting with error on most OOM
> situations.

dbus-python uses libdbus' OOM handling to handle OOM in the conventional
Python way, which is to raise a (preallocated!) MemoryError exception.
Python library user code can handle this in whatever way it sees fit
(which is almost always to propagate it all the way up to the
main()-equivalent, complain to stderr and exit unsuccessfully; but doing
something else is always an option).

One impression I've developed about libdbus is that the API is somewhat
confused about the purpose of the library. There are three classes of user:

* dbus-daemon

* applications ignoring your recommendations and using libdbus directly:
  the assumption seems to be that these want high-level convenience API,
  and this seems to have influenced the design of libdbus (varargs,
  simplest-possible error handling like not returning a DBusError
  if a boolean for "OOM?" would do, and the fact that exit_on_disconnect
  is on by default)

* language bindings: to be honest I wouldn't mind having a bit of extra
  boilerplate like "everything that can fail returns a recoverable
  DBusError". I don't mean straw-man things like returning a DBusError
  for things I can trivially check, like NULL where a valid pointer was
  expected; I mean things like dbus_connection_try_register_object_path,
  which I added a while ago (commit 557da174) to avoid causing unrecoverable
  assertions when a Python programmer tries to use the same object path
  twice.

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090113/d923de7c/attachment.pgp 


More information about the dbus mailing list