On 02/07/2011 09:52 PM, Guilhem Bichot wrote:
> Hello Jorgen,
>> >I have the goal to make get_current_struct() private soon if
>> >possible. So, nobody could access "the current struct"; it could just
>> >add objects/arrays (which implicitely adds them as children of the
>> >current struct), or pass down an object/array if a function wants to
>> >add to it.
>>
>> Ok, but can I please get this patch in first?
>
> Now that the range opt patch has been pushed, it's time to think about
> this get_current_struct().
> I suggest that the current structure (Opt_trace_array), which is created
> by handler::multi_range_read_info_const(), is passed by that creator to
> seq->next(), as a third parameter named "trace_array".
> So the signature of RANGE_SEQ_IF::next() would get a third parameter
> (minor change to handler API, quite probably ok in Fuchsia).
> If that *Opt_trace_array parameter is not NULL, next() would be expected
> to add to it (and it's not deadly if the engine implementing next()
> forgets to do that: the trace will just miss information). Only the
> default implementation of next() (sel_arg_range_seq_next()) would add to
> the array (as it is now: only sel_arg_range_seq_next() adds to the
> array; quick_range_seq_next(), bka_range_seq_next(),
> bka_unique_range_seq_next() don't).
> Then get_current_struct() would be deleted from Opt_trace_context, which
> is better for isolation.
>
> What do you think of this?
That's a good idea. Is the branch stable enough for me to do this now or should
I wait?
--
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway
