On Fri, Mar 18, 2016 at 02:02:08PM +0800, 惠轶群 wrote:
> I believe git-credential--daemon is a better place to comment on, but
> I'm not sure whether the comment should be included in this patch set.
> Above all, they are not quite related.
Yes, it could be completely separate from your series.
Here is what I think we should do:
-- >8 --
Subject: credential-cache--daemon: clarify "exit" action semantics
When this code was originally written, there wasn't much
thought given to the timing between a client asking for
"exit", the daemon signaling that the action is done (with
EOF), and the actual cleanup of the socket.
However, we need to care about this so that our test scripts
do not end up racy (e.g., by asking for an exit and checking
that the socket was cleaned up). The code that is already
there happens to behave very reasonably; let's add a comment
to make it clear that any changes should retain the same
behavior.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
credential-cache--daemon.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
index caef21e..291c0fd 100644
--- a/credential-cache--daemon.c
+++ b/credential-cache--daemon.c
@@ -126,8 +126,17 @@ static void serve_one_client(FILE *in, FILE *out)
fprintf(out, "password=%s\n", e->item.password);
}
}
- else if (!strcmp(action.buf, "exit"))
+ else if (!strcmp(action.buf, "exit")) {
+ /*
+ * It's important that we clean up our socket first, and then
+ * signal the client only once we have finished the cleanup.
+ * Calling exit() directly does this, because we clean up in
+ * our atexit() handler, and then signal the client when our
+ * process actually ends, which closes the socket and gives
+ * them EOF.
+ */
exit(0);
+ }
else if (!strcmp(action.buf, "erase"))
remove_credential(&c);
else if (!strcmp(action.buf, "store")) {
--
2.8.0.rc3.378.gf2f7872
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html