search

deltachat / deltachat-ios

Email-based instant messaging for iOS.
Other
327 stars 52 forks source link

when NSE is fetching, do not delay app start #2393

Closed r10s closed 1 week ago

r10s commented 2 weeks ago

this PR avoids the app being stale on startup for up to 30 seconds in case the NSE ("notification service extension") is not yet terminated. EDIT: the system may even terminate the app during that timeframe

instead, the app is started, but startIo() is delayed until the NSE has finished (which takes at max 30 seconds)

some background:

the core cannot handle multiple processes fetching concurrently, reason is that some IMAP fetch state (last seen UID?) is hold in RAM and not synced between processes (cc @link2xt is this still correct?)

Delta Chat iOS has currently up to three processes: main, share-extension, notification-service-extension.

share extension is fine as nothing is read from IMAP.

for the notification-service-extension we do a fetch using dc_accounts_background_fetch() - and if the user starts the mainapp in that time (max. 30 seconds), cannot start_io() - before this PR we delayed the app start - and now we delay start_io() only.

this is not great program-wise, but from the view if the user quite okay

link2xt commented 2 weeks ago

the core cannot handle multiple processes fetching concurrently, reason is that some IMAP fetch state (last seen UID?) is hold in RAM and not synced between processes

Last seen UID is stored in the database, but this does not prevent two processes from fetching the same message at the same time and storing it in the database.

r10s commented 2 weeks ago

ah i see. thanks for clarifying ❤️

would that really result in the message being added as two database rows practically? usually, there is the check for already-added-message-ids, or?

wondering, if the effort we're doing here is really needed - what would be the worse case? can we exclude database corruption (meaning, having the tables in a state that we eg. end in an endless loop)? if there are some rare races, that might be acceptable - also this complex code may have races and side effects ...

link2xt commented 2 weeks ago

The check for existing Message-ID is not atomic. You can start a few deltachat-repls on the same account and they will receive messages and add them multiple times to the chat. Besides that, there are other non-atomic changes like managing member list, creating contacts, peerstate (keys) etc., duplicated messages is just the most visible change.

r10s commented 2 weeks ago

thanks for the detailed info!

then we will stay withe the existing approach that is improved by this PR, np :)