Hey hey, On 12/05/17 16:18, Carlo Lobrano wrote: > > Maybe it wouldn't be a bad idea to keep track of which operations may >> fail due to SIM being busy, and perform automatic retry later if we >> get that specific error, something like that. > Hey, > > I made a little proof of concept of this improvement. So far, it's > restricted to *loading unlock retries again once #QSS:3* is received, but I > can't get to have the retries values updated at a higher level. This is > likely due to *mm-iface-modem.c:load_unlock_retries_ready* callback not > being called I guess, but I'm not really sure my approach is totally > correct. > > I do the following: > > A. When mm_telit_parse_csim_response fails: > 1. The *GSimpleAsyncResult* instance is saved > 2. load_unlock_retries is marked to be called again later > B. When QSS: 3 arrives: > 1. a newly *LoadUnlockRetriesContext* is created using the saved > *GSimpleAsyncResult* (the idea is to re-use the original callback > reference, but not really sure it's correct). > 2. *load_unlock_retries_step* is called again with the above mentioned > LoadUnlockRetriesContext instance > > Step 2 is done in a GSourceFunc called by the mainloop, using g_add_idle.
Hum... not sure this approach is the correct one. If you store the GSimpleAsyncResult and not complete it the whole logic in the MMIfaceModem will get stuck until it is completed afterwards. The logic in MMIfaceModem goes step by step, if one step takes 5 minutes to complete, the next steps won't go on until that happens. What I was thinking regarding this issue was to define a common error id, like "MM_CORE_ERROR_RETRY_LATER". If the logic (e.g. MMIfaceModem logic) receives such an error, it would re-schedule the execution of that step later on, in X seconds, but would still continue with the remaining steps in the logic it has. But this is really very specific to what we're loading, as not all steps may be retried later. For the specific case of loading unlock retries... does it make sense for us to report e.g. that the modem is "locked" but without being able to report the unlock retries left after some time later? From a user point of view, I'm sure that an application that receives notification that the modem is locked would expect right away to know the amount of unlock retries left, if we report that several seconds later the information will likely not be used at all. So I'm not sure whether this makes sense; waiting for "QSS: 3" guarantees that we'll be able to read unlock retries; but maybe it's just cleaner to perform several retries trying to load them as that may be quicker than waiting for "QSS: 3"... it really is very unfortunate that this notification takes so long to be emitted :/ -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
