Should we add a monitor to handle the prevent sync pattern ?

https://github.com/Scille/parsec-cloud/blob/956d139e09840536c18fcb4db3b19ec94b9cea11/libparsec/crates/client/src/workspace/store/mod.rs#L196

I guess this operation can take a long time in case the sync pattern is not currently fully applied and the workspace is big enough (I guess recursive_apply_prevent_sync_pattern doesn't need to download manifest that are not yet available, otherwise it's even worse performance wise)

The issue is obviously this slow down the startup of the workspace. Another approach would be to introduce a dedicated monitor that would:

on startup check the pattern is fully applied
listen on an event fired whenever the pattern change (so there should be a workspace.set_new_prevent_sync_pattern() that doesn't do the apply but only set the value and fire the event.
is responsible to run workspace_store.apply_prevent_sync_pattern() when needed (workspace_store.apply_prevent_sync_pattern() should probably have a lock to ensure it is never run more than once concurrently)
on top of that, the monitor could abort any pending workspace_store.apply_prevent_sync_pattern() if a new event is fired

This way the long operation is run in a dedicated coroutine and doesn't slow down anything else \o/

_Originally posted by @touilleMan in https://github.com/Scille/parsec-cloud/pull/7781#discussion_r1691340508_

Scille / parsec-cloud

Should we add a monitor to handle the prevent sync pattern ? #7799