Anything like GDestroyNotify in the mm api?

[Jessy Exum]

When I wrote the previous email, I had not actually tested cancelling the
operation. Now that I have, and a few dozen core dumps later, I realized
that the libmm-glib functions will call their callback function even if
there is a cancellation, and the XXX_finish function will report that there
was a cancellation. So now I understand why GDestroyNotify is unnecessary.
I think this issue is closed.

On Sun, Oct 4, 2020 at 11:00 PM Jessy Exum <jessy.diamondman at gmail.com>
wrote:

> Hello everyone,
>
> I am using MM in a C++ project, but my question won't be related to C++
> besides a very high level description of what I did.
>
> To get MM functions to invoke bound C++ functions as callbacks, I had to
> generate a small structure for each MM function call that automatically
> destroys itself once the callback fires. This works perfectly (mostly)!
>
> Except! If the MM function is cancelled, my wrapping structure is never
> invoked, never freed, and I get a memory leak. My current solution is to
> use g_cancellable_connect to trigger the struct's destruction when I cancel
> the MM operation. That is when I saw that g_cancellable_connect accepts an
> optional GDestroyNotify* callback, and I started thinking about how much
> more flexible the libmm-glib API would be if functions that accepted a
> GCancellable, callback, and userdata ALSO supported a GDestroyNotify style
> callback for freeing userdata.
>
> I know I can't expect a massive API change to a mature project because it
> would be convenient to one guy who is working in a different language, but
> I wanted to bring the idea up in case anyone else likes the idea, or knows
> why it was not implemented.
>
> Thanks to everyone who read through this, I look forward to your feedback.
>
> Stay safe,
> Jessy Diamond Exum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20201005/eeca33e6/attachment.htm>