GDaemonMount: invalidate mount cache whenever we unmount a mount

Otherwise, the old mount info, and in particular the (D-Bus unique name,
object path) pair representing it in its backend, will remain in
the cache until the backend process exits, which could take time.
Re-mounting and re-unmounting that mount would fail, because the
second Unmount() call would go to the unique name and object path of
the backend object that was destroyed by the first Unmount call,
not the backend object that is now responsible.

I'm using the Unmount reply rather than a signal, for thread-safety;
the mount cache is global, so if it was listening for the Unmounted
signal, that signal would be queued up for delivery to some
specific main-context, call it A. If another thread did the
umount/mount/unmount in main context B, before main context A was
dispatched, then the invalidation would be too late to help it.

This does not cover concurrent mount/unmount in two distinct main
contexts without any synchronization. However, if two threads in
main contexts B and C race to mount/unmount a share, then they're
sometimes going to lose anyway, and there isn't a great deal that
cache invalidation can do to help them.

0 files changed, 0 insertions, 0 deletions