> 
> > something that would be called when an iLock is destroyed, so that the
> > lock package can free its own data structures; and possibly init
> 
> As far as I can tell, iLocks aren't destroyed.  They are reference-counted,
> and if their ref count reaches zero, they are marked free and later reused 
> within their address buckets.  So in the worst case, you'll have 64 unused 
> native locks.
> 

 Wait--this is so not correct.

You can of course have more than 64 unused native locks if a lot of locks
are allocated and all references to them are released.

So I concur, we need an interface to destroy native locks.

Then the problem will be to decide when to destroy them; doing it everytime
the ref count reaches zero might be too expensive.  I would envision that
"garbage collecting" them periodically might be a better solution overall.

	- Godmar