[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue 15
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue 15 |
Date: |
Sun, 9 Jul 2006 19:53:23 -0700 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Sun, Jul 09, 2006 at 04:27:46PM -0700, Eric Anderson wrote:
> > Is the goal to cause an exception to be thrown if the process exits
> > quickly? Why would you want that?
>
> I had two usage problems running the benchmarks, the first was that
> occasionally, if I ctrl-c'd partway through a run because I decided I
> made a mistake, the mtn serve process would still be running. When
> the next bechmark run happened, it would fail to get the server going,
> but the client would find a server, run to completion, and only then
> report that there were no statistics in the server run. The sleep(1)
> and kill detected the error early on. There may be better ways. As I
> mentioned in the comment there was also some usage error I ran across
> -- the sub process was run with bad arguments, possibly while I was
> adding the instrumenter, but I can't remember exactly what the error
> was other than the sub process didn't really get started, and so this
> check caught that mistake as well.
Nod. There should definitely be more bulletproofing of the cleanup; I
ran into similar problems. (At least it gives the executable a unique
name, so you can 'killall mtn-server'...)
Your patch is totally wrong, though, unfortunately -- all command
executions go through here. With this patch, a benchmark for "db
init" will fail unless "db init" takes at least 1 second, which
hopefully it does not...
I'm not sure how to get better error-detection at startup time. The
code that starts the server (as opposed to the generic process
spawning code) could poll that the server was still alive before
starting the client, I guess... (it already has a sleep after starting
the server, to give it time to start up). Would just need to expose
another method on the Process object to let one check to see if a
process was still alive.
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen