pcp
[Top] [All Lists]

Re: Review: PCP & pmlogger take too long to start

To: Michael Newton <kimbrr@xxxxxxx>
Subject: Re: Review: PCP & pmlogger take too long to start
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Tue, 03 Jul 2007 09:07:58 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <Pine.SGI.4.58.0707021658520.7708406@xxxxxxxxxxxxxxxxxxxxxxx>
Organization: Aconex
References: <Pine.SGI.4.58.0706271012280.2186626@xxxxxxxxxxxxxxxxxxxxxxx> <Pine.SGI.4.58.0706271124250.2186626@xxxxxxxxxxxxxxxxxxxxxxx> <Pine.SGI.4.58.0706271715321.2351218@xxxxxxxxxxxxxxxxxxxxxxx> <1182996127.15488.102.camel@xxxxxxxxxxxxxx> <Pine.SGI.4.58.0706291810180.4792701@xxxxxxxxxxxxxxxxxxxxxxx> <1183355238.15488.217.camel@xxxxxxxxxxxxxx> <1183356141.15488.223.camel@xxxxxxxxxxxxxx> <Pine.SGI.4.58.0707021658520.7708406@xxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: nscott@xxxxxxxxxx
Sender: pcp-bounce@xxxxxxxxxxx
On Mon, 2007-07-02 at 17:02 +1000, Michael Newton wrote:
> 
> >Secondly, that branch is b0rken in that it will only ever print one
> >'.' character - its meant to print one dot every iteration (or every
> >second now, I guess).  You'll want to use an expr modulo (%) there.
> 
> dont understand. $i is incremented every time round. When it gets to
> 10
> * it gets reset to zero
> * j is incremented
> * '.' is printed
> 
> so $i counts tenths of a sec and $j counts whole seconds 

Yep, I thought $delay was the loop step when I wrote that (hadn't seen
the other two scripts then that really use it at that stage) - ignore
that comment.

> > The 'r' variable isn't really necessary -
> >see my attached patch that makes this slightly simpler.
> 
> very slightly! is there a reason to prefer "return" over "exit"? 

:) - yep, its trivial, couldn't help myself.  No reason for one over
the other here, only case I know of where you'd choose exit is if an
atexit handler is needed.

> yes it was intentional -- doesnt seem odd to me - why wouldnt you
> print one?
> Its consistent with the behaviour of say pmval when given a malformed
> -t value 

Fair enough.  My thinking was the errno from pmParseInterval might
not have anything to do with bad usage (like ENOMEM or something),
but I guess in practice it probably always does.

> btw i also aimed to keep the diffs minimal

If it comes down to simple-and-readable vs minimal-and-odd-looking,
I'd pick simple-and-readable every time - these scripts are hairy
enough already.

> of course i didnt originate this code but i think you have
> misinterpreted it.

*nod*, yep, I see it now.

> you know pmlogger is through its initialisation, but now
> you need to give it a little time to finish cleaning up the 
> connection you have just relinquished, so as to be ready to
> talk to a real client.

That bit I don't buy - the startup script uses pmlc to connect
as this guarantees that pmlogger is started up and ready - there
isn't any "little time" after a pmlc connection where pmlogger is
not available for another connection.  It seems that additional
sleep there is redundant - I'll ask Ken though when he's back if
he can remember why it was added (any chance you can do some rlog
sleuthing, see if it was added in response to a bug?).  Really odd
that it was a full three second sleep too.

The pmie script is based closely on the pmlogger one (was copied
at one point, by me) - so, the pmlogger behaviour and history there
is much more interesting.

cheers.

--
Nathan


<Prev in Thread] Current Thread [Next in Thread>