TODO

error:
- we should always push an error context before calling a handler that
  cannot return to indicate an error
- include a raised error in the context for errbacks, so the errback has to
  free it

main:
- there's an argument for making the main loop more generic; having io,
  watch, signal, child, timer, etc. just add main loop structs that
  have a select() and handle() function - we'd then just have one per
  timer, etc.
- we could do that using signalfd() and timerfd_*()
- use poll rather than select
- loop on signalfd read calling wait inside

io:
- there's a couple of tricky tests left to do:
- nih_io_message_recv() with socket types other than PF_UNIX
- nih_io_message_recv() when recv() fails
- nih_io_watcher() with write error and free called

timers:
- sub-second timer resolution (since select can do it)
- monotonic and realtime (using timerfd?)
- calendar scheduled timers

watch:
- inotify already has an IN_ISDIR flag to let us know that we got an event
  for a directory, so we don't really need to stat() it or pass a statbuf
  around; except maybe for compatibility with the walk code.
- handle IN_Q_OVERFLOW in some sane manner, at least log it.

allocator/slab module

string table:
- as hash, but massively optimised for tables of strings


dbus:
- NihDBusProxy should have an auto_start member, when TRUE any method calls
  will automatically start the remote end if it's not running

- structures are not defined anywhere
- default structure naming is not exactly ideal
  - should be possible to customise the names of the structures
  - should be possible to customise the names of the structure members

- missing tests for dict entry handling
  - dict entry handling could be better anyway (like in a hash?)

- we're not using the no_reply annotation
  - object implementation probably shouldn't - the client is free to ignore
    the annotation so might be waiting for a reply, so we should send one
    anyway
  - proxy implementation is interesting, because we need to wait for a reply
    to get an error return; we wouldn't want a sync function or even a notify
    function or even a pending call :-/

- doc strings for methods, signals, arguments, etc.
  - annotation would be used to set them
  - auto-generate doc strings for output functions

- what if we want both proxy and object code in one source?
  - right now, the method names would conflict
  - arrays would need to be generated for both