ModelTypeSyncBridge::MergeSyncData() should be async |
||
Issue descriptionModelTypeSyncBridge is an asynchronous interface that USS datatypes usually need to implement. Most of the methods there are asynchronous, but a few remain synchronous. In particular, MergeSyncData() is problematic, because it is expected that the bridge will perform a best-effort merge between local data (potentially requires I/O) and remote data (already fetched and in-memory). Because MergeSyncData() requires access to local data, it conceptually makes little sense that it remains synchronous, while other methods like GetData() or GetAllData() are asynchronous. In this new proposal, while a merge is ongoing, the bridge should expect no further remote updates, which the processor is responsible for. However, the local model might suffer changes, so bridges should handle this with care. The reason why we could survive without this for so long is that many datatypes either a) keep a copy of the data in memory, or b) live in the IO thread, and can block until data is read. However, we already have a few examples where such conditions don't meet, and other workarounds are used. One alternative API would be to instead make all methods synchronous, which would require that a number of bridges move to the IO thread.
,
Jul 12
As per latest discussions, we will likely do the exact opposite and make ModelTypeSyncBridge's API synchronous. In order to do that, ConsentSyncBridge and UserEventSyncBridge need to be moved to background threads.
,
Aug 10
triage ping: Mikel, can you comment on the timeline here when you come back from vacation?
,
Sep 9
sync-triage-ping with same comment as in #3 :)
,
Oct 24
As I mentioned in comment 2, I would like to do the exact opposite, but that depends on some ongoing work related to user events and consents. Meanwhile, no updates.
,
Jan 14
Closing this for now since plans are the exact opposite. |
||
►
Sign in to add a comment |
||
Comment 1 by bugdroid1@chromium.org
, Jul 11