TODO

dbus:
- could we do signal connection by nih_dbus_proxy_new?  If it took an
  interfaces list, that could point to auto-generated filter functions,
  and these would be automatically hooked up and called when the signal
  occurs
- binding tool needs to generate marshal functions for signals
- what if we want both proxy and object code in one source?  is there a way
  to just generate the arrays for both?

- properties need to be handled in some way

- async method calls with callback function
- could pass NULL callback to mean no reply expected
- need to set timeout and auto start flags somehow?

- binding tool needs to support structs
- binding tool needs to at least acknowledge variants

- rather than hard-coding the names of method and signal handler functions,
  it might be nice to have some kind of dispatch table for them.  The only
  concern is that we'd end up looking up in the interface table to find
  the marshaller then the dispatch table to get the handler function.

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_*()

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