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.diamond...@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 >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
