24 May
2022
24 May
'22
4:25 p.m.
On Tue May 24 16:09:54 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 5/24/22 01:12, Rémi Bernon (@rbernon) wrote: > On Mon May 23 23:15:33 2022 +0000, **** wrote: >> Zebediah Figura replied on the mailing list: >> \`\`\` >> On 5/23/22 07:07, Rémi Bernon wrote: >>> +static HRESULT asf_callback_create(struct asf_reader *filter, >> IWMReaderCallback **out) >>> +{ >>> + struct asf_callback *impl; >>> + >>> + if (!(impl = calloc(1, sizeof(*impl)))) >>> + return E_OUTOFMEMORY; >>> + >>> + impl->IWMReaderCallback_iface.lpVtbl = &reader_callback_vtbl; >>> + impl->filter = filter; >>> + impl->ref = 1; >>> + >>> + *out = &impl->IWMReaderCallback_iface; >>> + return S_OK; >>> +} >> Can we put the IWMReaderCallback interface inside of struct asf_reader, >> instead of making this a separate object? >> \`\`\` > > No, the reader will hold a ref on it and it would prevent filter destruction otherwise. > If it's the same object, the reader shouldn't be holding a reference. In fact I think they should be able to share the same refcount.If it's the same object, the reader shouldn't be holding a reference. In fact I think they should be able to share the same refcount.
The reader has no way to know that and it adds a ref to the callback interface as it should. I don't think we should decref ourselves after calling IWMReader_Open, that sounds pretty ugly.