On Thu, 5 Jan 2012, Jeff King wrote:
On Wed, Jan 04, 2012 at 06:24:16PM -0800, Jakub Narebski wrote:
quoted
Jeff King [off-list ref] writes:
quoted
As a side note, it looks like we just start the daemon with "git daemon
&". Doesn't that create a race condition with the tests which
immediately try to access it (i.e., the first test may run before the
daemon actually opens the socket)?
Hmmm... perhaps the trick that git-instaweb does for "plackup" web
server would be of use here, waiting for socket to be ready?
It looks like it busy loops, which is kind of ugly.
Well, as far as I know you can wait for data on socket or pipe, but
you can't wait for socket to be created.
Anyway this busy-wait is not too busy, and it is better than just
adding 'sleep 1' in testsuite.
The credential-cache helper has a similar problem. It wants to kick off
a daemon if one is not already running, and then connect to it. So the
daemon does:
printf("ok\n");
fclose(stdout);
when it has set up the socket, and the client does:
r = read_in_full(daemon.out, buf, sizeof(buf));
if (r < 0)
die_errno("unable to read result code from cache daemon");
if (r != 3 || memcmp(buf, "ok\n", 3))
die("cache daemon did not start: %.*s", r, buf);
/* now we can connect over the socket */
We could probably add a "--notify-when-ready" option to git-daemon to
do something similar.
What would git-daemon do what it is ready? Write to socket, raise signal,
print to STDOUT / STDERR?
BTW. I wonder if it would be worth it to add something a la systemd
trick creating sockets first to git-daemon. Adding systemd support
doesn't make sense for daemon that is to be run from inetd / xinetd,
I guess.
--
Jakub Narebski
Poland