1.1 --- a/docs/wiki/Mechanisms Thu Mar 24 22:11:47 2022 +0100
1.2 +++ b/docs/wiki/Mechanisms Fri Mar 25 01:20:33 2022 +0100
1.3 @@ -206,3 +206,40 @@
1.4 }}}
1.5
1.6 ########
1.7 +
1.8 +The `ResourceRegistry` coordinates access to filesystem resources and, through
1.9 +synchronisation, prevents conflicting operations from occurring concurrently.
1.10 +For example, a removal operation on a file may not be allowed to occur while
1.11 +an opening operation is in progress.
1.12 +
1.13 +To achieve this, a common lock is employed to serialise access, with any
1.14 +underlying filesystem operations being initiated from the registry while the
1.15 +lock is held. An object providing the `FileOpening` interface for a filesystem
1.16 +provides such operations, and the following interaction pattern is thereby
1.17 +employed:
1.18 +
1.19 +######## A graph showing the registry coordinating filesystem operations
1.20 +
1.21 +{{{#!graphviz
1.22 +#format svg
1.23 +#transform notugly
1.24 +digraph registry_operations {
1.25 + node [fontsize="12.0",fontname="sans-serif",shape=box];
1.26 + edge [fontsize="12.0",fontname="sans-serif"];
1.27 + rankdir=LR;
1.28 +
1.29 + OpenerContextResource -> OpenerResource -> ResourceRegistry -> FileOpening;
1.30 +}
1.31 +}}}
1.32 +
1.33 +########
1.34 +
1.35 +Since the `ResourceRegistry` functionality is generic, it could be specialised
1.36 +for each filesystem or be configured with an appropriate reference to a
1.37 +`FileOpening` object. The `OpenerResource` would then be generic, invoking the
1.38 +registry which would, in turn, invoke the opening object.
1.39 +
1.40 +However, the chosen approach is to permit `OpenerResource` objects to
1.41 +implement the `FileOpening` interface for each filesystem, meaning that the
1.42 +`ResourceRegistry` will end up being called by the opener and then invoking
1.43 +the opener in return.