Re: [Xen-devel] [PATCH 11/24] golang/xenlight: define CpuidPolicyList builtin type

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel