Commit 77ccb352 authored by Kirill Smelkov's avatar Kirill Smelkov

.

parent 4c6eb79e
...@@ -51,7 +51,7 @@ ...@@ -51,7 +51,7 @@
// ... // ...
// //
// where head/ represents latest data as stored in upstream ZODB, and // where head/ represents latest data as stored in upstream ZODB, and
// @<revX>/ represents data as of revision <revX>. // @<revX>/ represents data as of database revision <revX>.
// //
// head/ has the following structure: // head/ has the following structure:
// //
...@@ -150,13 +150,19 @@ ...@@ -150,13 +150,19 @@
// //
// A later request from the client for the same <bigfileX> but with different // A later request from the client for the same <bigfileX> but with different
// <at>, overrides previous watch request for that file. A client can use "-" // <at>, overrides previous watch request for that file. A client can use "-"
// instead of "@<at>" to stop watching the file. // instead of "@<at>" to stop watching a file.
// //
// A single client can send several watch requests through single head/watch // A single client can send several watch requests through single head/watch
// open, as well as it can use several head/watch opens simultaneously. // open, as well as it can use several head/watch opens simultaneously.
// The server sends pin notifications for all files requested to be watched via // The server sends pin notifications for all files requested to be watched via
// every head/watch open. // every head/watch open.
// //
// Note: a client could use a single watch to manage its several views for the same
// file but with different <at>. This could be achieved via watching with
// @<at_min>, and then deciding internally which views needs to be adjusted and
// which views need not. Wcfs does not oblige clients to do so though, and a
// client is free to use as many head/watch openenings as it needs to.
//
// When clients are done with @<revX>/bigfile/<bigfileX> (i.e. client's // When clients are done with @<revX>/bigfile/<bigfileX> (i.e. client's
// transaction ends and array is unmapped), the server sees number of opened // transaction ends and array is unmapped), the server sees number of opened
// files to @<revX>/bigfile/<bigfileX> drops to zero, and automatically // files to @<revX>/bigfile/<bigfileX> drops to zero, and automatically
...@@ -170,8 +176,8 @@ ...@@ -170,8 +176,8 @@
// server will become blocked waiting for pin acknowledgments, and thus all // server will become blocked waiting for pin acknowledgments, and thus all
// other clients, that try to work with the same file, will get stuck. // other clients, that try to work with the same file, will get stuck.
// //
// The problem could be avoided, if wcfs would reside in OS kernel and this way // The problem could be avoided, if wcfs would reside inside OS kernel and this
// could be able to manipulate clients address space directly (then // way could be able to manipulate clients address space directly (then
// invalidation protocol won't be needed). It is also possible to imagine // invalidation protocol won't be needed). It is also possible to imagine
// mechanism, where wcfs would synchronously change clients' address space via // mechanism, where wcfs would synchronously change clients' address space via
// injecting trusted code and running it on client side via ptrace to adjust // injecting trusted code and running it on client side via ptrace to adjust
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment