.

wcfs/wcfs.go

@@ -165,26 +165,27 @@
 //
 // Protection against slow or faulty clients
 //
-// If a client, on purpose or due to a bug or being stopped, is slow to
-// respond with ack to invalidation notification, it creates a problem because
-// head/data updates will be blocked and thus all other clients that try to
-// work with current data will get stuck.
+// If a client, on purpose or due to a bug or being stopped, is slow to respond
+// with ack to file invalidation notification, it creates a problem because the
+// server will become blocked waiting for pin acknowledgments, and thus all
+// other clients, that try to work with the same file, will get stuck.
 //
-// To avoid this problem it should be possible for wcfs to stop a client with
-// ptrace and change its address space in a style similar to e.g.
-// VirtualAllocEx on Windows. Here is hacky example how this could be done on Linux:
+// The problem could be avoided, if wcfs would reside in OS kernel and this way
+// could be able to manipulate clients address space directly (then
+// invalidation protocol won't be needed). It is also possible to imagine
+// mechanism, where wcfs would synchronously change clients' address space via
+// injecting trusted code and running it on client side via ptrace to adjust
+// file mappings.
 //
-// https://gist.github.com/rofl0r/1073739/63f0f788a4923e26fcf743dd9a8411d4916f0ac0
+// However ptrace does not work when client thread is blocked under pagefault,
+// and that is exactly what wcfs would need to do to process invalidations
+// lazily, because eager invalidation processing results in prohibitively slow
+// file opens. See internal wcfs overview for details about why ptrace
+// cannot be used and why lazy invalidation processing is required.
 //
-// This way there should be no possibility for a client to block wcfs
-// indefinitely waiting for client's ack.
-//
-// Similarly for initial mmapings client could first mmap head/data, then open
-// head/invalidations and tell the server that it wants Cat revision, with
-// the server then remmaping blocks to get to Cat state via ptrace.
-//
-// However for simplicity the plan is to go first without ptrace and just kill
-// a slow client on, say 30 seconds, timeout.
+// Lacking OS primitives to change address space of another process and not
+// being able to work it around with ptrace in userspace, wcfs takes approach
+// to kill a slow client on 30 seconds timeout by default.
 //
 //
 // Writes
@@ -299,7 +300,7 @@ package main
 //    δFtail.by   allows to quickly lookup information by #blk.
 //
 //    min(rev) in δFtail is min(@at) at which head/data is currently mmapped (see below).
-//    XXX min(10 minutes) of history to support initial openenings
+//    XXX min(10 minutes) of history to support initial openings
 //
 // 7) when we receive a FUSE read(#blk) request to a file/head/data we process it as follows:
 //
@@ -336,9 +337,10 @@ package main
 //	  - client.remmap(file, #blk, @rev/data)
 //	  - mmapping.pinned += blk
 //
-//	remmapping is done synchronously via ptrace.
-//	XXX via running wcfs-trusted code wcfs injects into clients.
-//	FIXME ptrace won't work when client thread is blocked under pagefault or syscall(~).
+//	remmapping is done via "invalidation protocol" exchange with client.
+//	( one could imagine adjusting mappings synchronously via running
+//	  wcfs-trusted code via ptrace that wcfs injects into clients, but ptrace
+//	  won't work when client thread is blocked under pagefault or syscall(~) )
 //
 //	in order to support remmapping for each file/head/data
 //