From 25c687d5c5fe0371131839ac635b28e00f8776bb Mon Sep 17 00:00:00 2001 From: Bill Zissimopoulos Date: Tue, 6 Dec 2016 15:25:59 -0800 Subject: [PATCH] doc; winfsp-ipc: update document --- doc/winfsp-ipc.adoc | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/winfsp-ipc.adoc b/doc/winfsp-ipc.adoc index 12e0662e..fe86ea4c 100644 --- a/doc/winfsp-ipc.adoc +++ b/doc/winfsp-ipc.adoc @@ -12,6 +12,7 @@ In the following we will also use the notation [U] to denote user mode processin Consider then what happens when an OP issues a synchronous (non-overlapped), non-cached (non-buffered) WriteFile call. +ifdef::env-browser[] [uml,file="winfsp-ipc/synchronous.png"] -- hide footbox @@ -44,9 +45,12 @@ note over FSK, FSU #Salmon Salmon color denotes WinFsp processing. end note -- +endif::env-browser[] +ifndef::env-browser[image::winfsp-ipc/synchronous.png[]] Let us now consider what happens when an OP issues an asynchronous (overlapped), non-cached (non-buffered) WriteFile call. This scenario does not show how the OP receives the WriteFile result. +ifdef::env-browser[] [uml,file="winfsp-ipc/asynchronous.png"] -- hide footbox @@ -85,6 +89,8 @@ note over FSK, FSU #Salmon Salmon color denotes WinFsp processing. end note -- +endif::env-browser[] +ifndef::env-browser[image::winfsp-ipc/asynchronous.png[]] It should be noted that from the WinFsp perspective both cases look similar. WinFsp processing occurs: @@ -99,6 +105,7 @@ The TRANSACT calls are DeviceIoControl requests that the FS issues to WinFsp. A Let us now consider what may happen with two simultaneous API Requests from two different processes. For example, two WriteFile requests for different files. +ifdef::env-browser[] [uml,file="winfsp-ipc/multiple.png"] -- hide footbox @@ -154,6 +161,8 @@ note over FSK, FSU #Salmon Salmon color denotes WinFsp processing. end note -- +endif::env-browser[] +ifndef::env-browser[image::winfsp-ipc/multiple.png[]] Notice that it is possible for the FS to process multiple file system requests without context switching.