Mirage cstruct ownership clarification

I’m trying to get my head around some mirage code. When it talks about a function having ownership of a cstruct does that mean that when the function exits that the cstruct’s memory is deallocated?

Additionally if that cstruct is passed into something like a Lwt_stream will ownership of it travel with it?

Under the cstruct type, we have the bigarray type which is like the bytes type. So when we said that we take the ownership on it, that mostly means we will write something inside.

So, according the documentation, if you pass a cstruct to a function which will take the ownership, you are not able to write or read safely into a concurrent/parallel context (like with lwt).

The cstruct will be safe to manipulate only after the computation of the function. If you are interesting, cstruct comes with a capabilities interface which allow to enforce some assumptions with the type system like a read-only cstruct but it still is an experimental API.

Ah that is quite a nice way to think about it. With regards to the capabilities api does it do static checking via the type system?

Thanks regardless, I haven’t found a good reference for a lot of this stuff yet!

All the documentation is available here. This sub-module adds just some constraints and it does not resolve the ownership problem. If you want to understand underlying tasks, you should take a look on mirage/ocaml-cstruct#237 which has an interesting discussion with many peoples.

Then, again, it’s an experimental interface and we did not use yet into a real project.

1 Like

Ok cool I’ll have a poke around it :slight_smile:. Probably won’t use it for this project but might for the next one…