Resource ownership rules when integrating with C++

[yfinkelstein]

These questions apply to both embedded JIT mode as well as to "as a shared library" mode.

On Codon side:

extern
def f1(s:str) -> str

On C++ side

struct CodonString {
  seq_int_t len;
  char *str;
};

extern "C" CodonString  f2( CodonString s);

Questions:

1. C++ side invokes f1:

• Who owns string memory in incoming argument s ? If it's codon - can C++ "ref count" it and later unref or it must copy ?
• Who owns string memory of return string? C++ has generated this string by allocating it with seq_alloc_atomic. But who will release it and when?

2. Codon side invokes f2:

• Who owns string memory in s?
• Who owns string memory of return string?

These rules must be explained and documented.

Thanks!

[arshajii]

If you're creating the strings with seq_alloc_atomic() (like Codon does internally), then they're registered with the GC and don't need to be manually freed; they'll be collected automatically by the GC. (If you're also storing those strings in some other heap-allocated memory, be sure to register that with the GC to avoid premature collection -- see https://github.com/bdwgc/bdwgc).

Same thing on the Codon side if f2 is invoked by Codon, assuming seq_alloc_atomic() was used. If not, then Codon's GC will never free the memory and it should be freed on the C++ side when appropriate.