[pulseaudio-discuss] [Vala] Issues will vala and pulse vapi
Evan Nemerson
evan at coeus-group.com
Sat Nov 21 22:49:16 PST 2015
On Sat, 2015-11-21 at 23:37 -0600, Aaron Paden wrote:
> On Sat, Nov 21, 2015 at 11:07 PM, Evan Nemerson <evan at coeus-group.com
> > wrote:
> > On Sat, 2015-11-21 at 22:45 -0600, Aaron Paden wrote:
> > > On Sat, Nov 21, 2015 at 9:54 PM, Evan Nemerson <evan at coeus-group.
> > > com>
> > > wrote:
> > > >
> > > > That's not quite right; the VAPI shouldn't indicate that a
> > > > *type*
> > > > is
> > > > "unmanaged"… it's up to your code to indicate whether an
> > > > instance
> > > > is
> > > > unowned. However, the question is really what the proper way
> > > > to
> > > > destroy an instance is.
> > > >
> > > > In order to determine how to destroy a struct which doesn't
> > > > specify
> > > > a
> > > > destroy_function CCode attribute, Vala will look at the
> > > > members. If
> > > > none of the members require destroy or free functions, then
> > > > Vala
> > > > can
> > > > assume that simply releasing the memory associated with the
> > > > struct
> > > > itself (i.e., calling g_free on heap-allocated instances, or
> > > > simply
> > > > allowing stack-allocated instances to go out of scope) is
> > > > sufficient.
> > >
> > > Hum. Sourceinfo (and SinkInfo) should not be freed at all, the C
> > > APIs
> > > that retrieve them give you const pointers.
> >
> > Then they should return an unowned reference.
>
> Is it possible to do this when the pointer is an argument? These
> types
> are requested and then asynchronously retrieved via callbacks.
Arguments are unowned by default. Just don't copy it into an owned
variable and you should be fine.
Looking at your original example, it looks like you create a
Gee.ArrayList<PulseAudio.SourceInfo?>. Try Gee.ArrayList<unowned
PulseAudio.SourceInfo?>.
That said, I have no idea if you can count on the SourceInfo instances
surviving past the end of the callback invocation. If it doesn't you
probably need to create a copy of the whole struct, and you're back at
the issue of how whether the various fields should be owned or not,
which is something I can't answer.
More information about the pulseaudio-discuss
mailing list