On Thu, 5 Jan 2012, Jeff King wrote:
> On Wed, Jan 04, 2012 at 06:24:16PM -0800, Jakub Narebski wrote:
>
> > Jeff King <peff@xxxxxxxx> writes:
> >
> > > 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
--
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