Cleaning up SIM hot swap

[Eric Caruso]

On Mon, Jul 10, 2017 at 12:11 AM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
> On Sat, Jul 8, 2017 at 12:52 PM, carlo <c.lobrano at gmail.com> wrote:
>>
>> > While trying to implement setup_sim_hot_swap for MBIM modems, I
>> > noticed that I am setting up and enabling unsolicited events for
>> > SUBSCRIBER_INFO type notifications, but not cleaning them up. This
>> > might not end up affecting the user since the destruction of the
>> > modem
>> > object will disconnect the signal handler, but it means I might be
>> > leaving the modem in a weird state when it's disabled or unplugged
>>
>> consider that the modems might not keep this configuration after
>> reboot, unless you've explicitly saved it with a proper command. At
>> least, this is the behavior of Telit modems, whose plugin is the only
>> one that currently implements sim hot swap in modemmanager.
>
>
> Yeah, that's true, and it definitely is the case also for MBIM notifications.
>
> Plus, even if it's a good idea to request to disable the
> SUBSCRIBER_INFO notifications, it isn't critical if it fails, and
> therefore you don't really need to chain up 2 async methods: just
> issue the async MBIM calls with a NULL callback and go on
> synchronously (i.e. you run the MBIM command but don't wait for the
> result of the operation). Another option would be to pass a valid
> callback BUT also keep on synchronously, the callback would just e.g.
> log warning if the operation fails.
>

It's still not clear where I can safely queue up these asynchronous
operations without them possibly being scheduled to run after the
destruction of the object and the MBIM port. It seems like the dispose
method is the wrong place to do that, as I imagine that all but
guarantees that we'll have cleaned up those objects by the time the
asynchronous operations run.