Re: [Monotone-devel] oprofile data for mtn 0.37.

[Zack Weinberg]

On Thu, Mar 13, 2008 at 12:52 PM, Jack Lloyd <address@hidden> wrote:
> On Thu, Mar 13, 2008 at 12:07:57PM -0400, Zack Weinberg wrote:
>  >
>  > Is *all* storage reclaimed, or is there some array indexed by message
>  > number that's going to keep growing forever if I recycle pipes?
>
>  It should be everything (ie, zero increased memory usage over time, as
>  long as you read the entire contents of each message out) - the code
>  handling this is in out_buf.cpp if you would like to review.

Ok, good.

>  Message numbers are currently stored as 32-bit integers, and there
>  will probably be failures on overflow (in particular at 2^32-2 ==
>  Pipe::LAST_MESSAGE) -- how likely would a process-persistent Pipe
>  eventually hit this limit in (say) long-running a monontone server?

This is worrisome; a netsync server on a large repository might be
doing thousands of hex encoding operations per revision transferred,
which would add up fast.  And it's precisely that  operation we want
to speed up by avoiding creation of new Pipes per operation.

(yes, we are trying to reduce the incidence of those, but ...)

>  The message number can (and probably should) be changed to a long
>  long, though also the underlying issue that Pipe should detect/signal
>  this condition needs fixing.

Why not recycle message numbers once completely consumed?

zw