[tech] Mac stuff

[David Luyer]

I wrote:

> My current approach is to attempt to avoid data that has to be
> free'd - which isn't going to always be possible, but in many
> cases it is possible and again a speedup to avoid allocating and
> deallocating memory.

...of course this doesn't stop the memory from having been re-used.

The way to do this without the code having to know about it is:

  * the "add handler" handles locking the passed data
  * the "execute handler"
             1. checks the data is valid, else drops the handler
                and unlocks (once) without executing the handler
             2. executes the handler (which may add a new handler
                and lock) and then unlocks the data (once, ie,
                leaving it locked if it was multiply locked)
  * the "remove handler" handles unlocking the data
  * the data is implicitly valid until invalidated
  * override "free" with something which will detect locked
    data and invalidate rather than free
  * in the unlock code, if the data is invalidated and you're
    removing the final lock, free it

But this also fails.  It fails where the data is _not_ malloc()d
but _is_ now invalid (because an explicit invalidation is needed,
the locking/unlocking/invalidation is not fully transparent).
There's always a need for some policy and avoiding these problems
can be easy or hard depending on the complexity of the underlying
project.

David.