Re: pa_cstruct first cut available

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 10 May 2012, at 17:33, Thomas Gazagnaire wrote:
> 
>> One thing I might need to extend the bigarray stubs for is that you can't 
>> register a *custom* finaliser. Each bigarray can either be CAML_BA_MANAGED 
>> (i.e. the runtime allocated the bigarray and should free it), or 
>> CAML_BA_MAPPED_FILE (mmap, so needs an munmap), or CAML_BA_EXTERNAL 
>> (something else, take no action).
>> 
>> Right now, the runtime takes no action for CAML_BA_EXTERNAL, but we need to 
>> be able to register a custom finaliser, so that we can do something 
>> interesting with the underlying resource in Xen (mostly putting it back into 
>> the Io_page pool for re-use).  This would also be useful in UNIX to 
>> similarly pool pages rather than going to expensive malloc and free all the 
>> time.
>> 
>> Are you familiar with that code? Something upstreamable for ocaml-4.0 (or 
>> indeed, if there's another way to do what I want) would be helpful so we 
>> don't need to maintain a custom patch...
> 
> yes, I've hacked few things there for numcaml one year ago, so I can try to 
> remember how it is working :-) Regarding the upstreamable patch, I guess 
> that's just adding few line in caml_ba_finalize..

Hm, the problem is that the caml_ba_proxy isn't an OCaml value, and so an OCaml 
finaliser can't be directly attached to it. 

What we really want is a shared finaliser that's only called when the 
underlying caml_ba_proxy hits zero.  We *could* stash a finaliser value in the 
proxy as a new field (and register it as a generational root?), and invoke it 
in caml_ba_finalize.

This requires forking Bigarray, so I'll do that do that for now (call it 
Extbuffer or something) and then generate a patch for Mantis.

-anil