On 04/12/2016 06:55 AM, Stan Hu wrote:
In the stateless RPC case, the server should respond to the client's depth
request with the set of commits which are no deeper than the desired
depth. Once this finishes, the server should terminate and receive the reply
in another POST request.
Previously the server would sit idle and die when it detected the client
closed the connection.
Some loose thoughts about the wording(s):
the server did not terminate (it's a machine, a hardware), a process
terminated.
And it did not "die" either, it terminates gracefully.
How about something like this:
In the stateless RPC case, the server responds to the client's depth
request. Once this finishes, the server should terminate.
The reply is and received in another POST request.
Previously the server would sit idle and terminates when it detected the client
closed the connection.
---------------
But, but,
there is may be more.
What happens, when the server process calls exit(0) ?
Is there a guarantee that the data is send out on the socket?
Or is the exit(0) ripping out all the data in the TCP send buffers,
and the client may, or not may, receive the complete packets.
Beside that, a close() of a socket means that the socket is going into
time_wait() state.
Is this desirable for a server to have many sockets in time_wait ?
(This is out of my head, I may be wrong)
Could it be that the client is broken ?
Could you elaborate this a little bit more ?
Signed-off-by: Stan Hu <stanhu@xxxxxxxxx>
---
upload-pack.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/upload-pack.c b/upload-pack.c
index b3f6653..4fb1e60 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -676,6 +676,8 @@ static void receive_needs(void)
register_shallow(object->oid.hash);
}
packet_flush(1);
+ if (stateless_rpc)
+ exit(0);
} else
if (shallows.nr > 0) {
int i;
--
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