> If we do have to keep the C pointer around for some reason, I think > using SetFinalizer is a necessary backstop to keep the library from > leaking. It's all well and good to say, "Make sure you call Dispose()", > but I think for a GC'd language that's just going to be too easy to > forget; and it will be a huge pain for long-running processes.
I understand your motivation for wanting to make this fool-proof, but there are plenty of common examples in Go where it's well-understood that if I call `NewFoo` then I need to `foo.Close()` (defer'd or otherwise). I don't think that alone is a good enough argument for turning to SetFinalizer. But, I'm certainly not advocating for the Dispose option either - as I said I think that would be unfortunate from an API perspective. > If we didn't have this type as a type, we'd have to avoid somehow > exposing the user to the functions which take and use it. The main > place it's used ATM is in DomainBuildInfo. We could explore whether it > would be practical to "implement" CpuidPolicyList as a string, and then > have toC() call libxl_cpuid_parse_config(). Obviously that means > fromC() would fail; but I'm not sure DomainBuildInfo is really a > structure passed "out" of libxl anyway. It's sounding more and more like we need a way to give types an "exported/unexported" attribute in the IDL. Why exactly would fromC be doomed to fail? Just because there is no `libxl_cpuid_to_string` or otherwise? In any case, I think defining it as a string may be a good intermediate option for now (even if it means fromC has to be a no-op). That way we can ensure calls to `libxl_cpuid_dipose` as usual. -NR _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
