Re: Order "begin" probes are run

[Mike Mason <mmlnx at us dot ibm dot com>]

Stone, Joshua I wrote:
> On Wednesday, November 29, 2006 1:57 PM, Stone, Joshua I wrote:
> > On Wednesday, November 29, 2006 1:23 PM, Frank Ch. Eigler wrote:
> > > Mike Mason <mmlnx@us.ibm.com> writes:
> > > > Seems reasonable to expect tapset "begin" probes to always run
> > > > before a script's "begin" probe. [...]
> > > One might also imagine cases where it could work the other way.
> > >
> > > We could solve this by parametrizing: adding a sequence parameter to
> > > "probe begin(N)" (and "end(M)"), and sorting them.  Easy to
> > > implement. 
> > This is a nice idea -- if you make the default priority zero for those
> > who don't specify it, then things can "just work".  Users can write an
> > unparameterized 'begin' as usual, and the tapset writer can initialize
> > in a 'begin(-1)' -- or 'begin(-2^63)' if paranoia kicks in...
>
> This is now implemented -- you can give a numeric parameter to begin/end
> probes, and they will execute in increasing order.  The sequence number
> if left out is effectively zero.

Thanks Josh!  I just tried your implementation and it works great.  Just what I needed.

> We should adopt a convention for tapset writers to use these fields.  My
> suggestion: when it doesn't matter, just use begin/end without a
> parameter; to run early, use less than -1000; and to run late use
> greater than 1000.  This way script writers still have +/- 1000 to play
> with locally.

I agree.

Thanks,
Mike