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

[Jack Lloyd]

On Thu, Mar 13, 2008 at 01:34:54PM -0400, Zack Weinberg wrote:
> On Thu, Mar 13, 2008 at 1:21 PM, Jack Lloyd <address@hidden> wrote:
> >  > Why not recycle message numbers once completely consumed?
> >
> >  This would actually work in many cases, BUT would probably fail
> >  horribly if the app doesn't actually read out all of the message data.
> >  For instance
> >
> >   write one message M1, dont't read it back
> >   write 2^32-1 messages, reading each one back
> >   write one message M2
> >
> >  Now if you ask for the contents of message 0, you get M1 || M2.
> 
> I don't follow you there.  M1 is not completely consumed, so it's
> still message 0; in this scenario, I was imagining M2 would be message
> 1?  (Think process IDs.)

OK I get it now. The problem is, how does the app know what message it
is on? I suppose start_msg / end_msg could return the newly
'allocated' message #, for later passing to read_*()... currently you
get a nice simple ordering of message numbers. That is particularly
important when you are using a Fork(), etc; you can't just use
LATEST_MESSAGE there so instead the idiomatic style (such as it is) is

 Pipe p(new Fork(new Filter1(), new Filter2()));
 for(int i = 0; i != msgs; i++)
   {
   p.process_msg(get_msg(i));

   // This is the result of Filter1(get_msg(i))
   SecureVector<byte> f1 = p.read_all(i*2);

   // This is the result of Filter2(get_msg(i))
   SecureVector<byte> f2 = p.read_all(i*2+1);
   }

Which assumes incrementing values.

-Jack