Re: Safely allocating memory in places enabled world

At Sat, 30 Sep 2017 09:45:02 -0700, Eric Dobson wrote:
> I'm trying to write some racket code which interfaces with a foreign
> library and provides a safe interface. Some of the functions I'm calling
> allocate memory and need to have this explicitly freed by the caller. The
> 'allocator' binding from ffi/unsafe/alloc seems to solve this problem, but
> I'm running into issues using it from places other than the main one. The
> issue is that if a place gets shut down then the finalizer that was
> registered don't seem to run, and I can observe the leaked memory at the
> process level.
> 
> I took a look at ffi/unsafe/custodian and it seems that
> register-custodian-shutdown would allow this to be implemented. Is there a
> reason that such allocator doesn't do this by default?

The simple answer is that I didn't think about places originally, but
there are some challenges beyond just wiring in a custodian hook.

If we change `ffi/unsafe/alloc` so that a custodian shutdown runs all
deallocators, that would work in many cases. It would create a problem,
however, if there are objects to deallocate where the deallocation
function references other objects that themselves must be deallocated.
That is, an allocated value A might depend on an allocated value B up
until the point that A has been deallocated. That dependency can be
expressed to `ffi/unsafe/alloc` (via the garbage collector) by
including a reference to B in the deallocation closure for A. Setting
up dependencies that way is not common, but I'm pretty sure I've used
that pattern once or twice. Meanwhile, there's no similar way to order
callbacks that are registered with a custodian.

I'm tempted to say that `ffi/unsafe/alloc` should only be used for
objects where the deallocation order doesn't matter, so that
deallocators can be triggered by a custodian shutdown. But an
additional constraint is needed: values to be deallocated cannot be
used by any other custodian-shutdown callbacks. That additional
constraint seems too limiting.

Maybe we need to add some sort of ordering constraints to custodians,
but I'm not immediately sure of the right way to do that.

-- 
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
For more options, visit https://groups.google.com/d/optout.