Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue 15

[Nathaniel Smith]

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