| Message ID | 22eec60761a88107b2e337ce13eed1020352aa73.1613598529.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 92ac4a38741912335a9241101a3e725acdf01083 |
| Headers | show |
| Series | Simple IPC Mechanism | expand |
"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > +How the simple-ipc server is started is also outside the scope of the > +IPC mechanism. For example, the server might be started during > +maintenance operations. Just a tiny nit. I would expect to see "might be <re>started" if it is followed by "during maintenance operations"; in other words, I expect "might be started" to be followed by "as part of the boot-up sequence". > +The IPC protocol consists of a single request message from the client and > +an optional request message from the server. For simplicity, pkt-line > +routines are used to hide chunking and buffering concerns. Each side > +terminates their message with a flush packet. > +(Documentation/technical/protocol-common.txt) Hidign chunking and buffering concerns is good, but it introduces some limitations, like 64k chunk limit, which probably want to be mentioned (if not explained or described) here. Do we give any extra meaning over "here, a message ends" to the flush packet? The lack of "now it is your turn to speak" (aka "delim") has long been a weakness of the over-the-wire protocol, and we'd probably want to learn from the past experience. > +The actual format of the client and server messages is application > +specific. The IPC layer transmits and receives an opaque buffer without > +any concern for the content within. Please sell why such a semantic-agnostic layer exists and what benefit the callers would get out of it. Perhaps you offer some mechanism to allow them to send and receive without having to worry about deadlocks[*]? THanks. [Footnote] *1* ...just an example benefit that may or may not exist.
diff --git a/Documentation/technical/api-simple-ipc.txt b/Documentation/technical/api-simple-ipc.txt new file mode 100644 index 000000000000..670a5c163e39 --- /dev/null +++ b/Documentation/technical/api-simple-ipc.txt @@ -0,0 +1,34 @@ +simple-ipc API +============== + +The simple-ipc API is used to send an IPC message and response between +a (presumably) foreground Git client process to a background server or +daemon process. The server process must already be running. Multiple +client processes can simultaneously communicate with the server +process. + +Communication occurs over a named pipe on Windows and a Unix domain +socket on other platforms. Clients and the server rendezvous at a +previously agreed-to application-specific pathname (which is outside +the scope of this design). + +This IPC mechanism differs from the existing `sub-process.c` model +(Documentation/technical/long-running-process-protocol.txt) and used +by applications like Git-LFS. In the simple-ipc model the server is +assumed to be a very long-running system service. In contrast, in the +LFS-style sub-process model the helper is started with the foreground +process and exits when the foreground process terminates. + +How the simple-ipc server is started is also outside the scope of the +IPC mechanism. For example, the server might be started during +maintenance operations. + +The IPC protocol consists of a single request message from the client and +an optional request message from the server. For simplicity, pkt-line +routines are used to hide chunking and buffering concerns. Each side +terminates their message with a flush packet. +(Documentation/technical/protocol-common.txt) + +The actual format of the client and server messages is application +specific. The IPC layer transmits and receives an opaque buffer without +any concern for the content within.