On 01/25, Brandon Williams wrote:
> On 01/25, Junio C Hamano wrote:
> > Brandon Williams writes:
> >
> > >> In my mind, the value of having a constant check_attr is primarily
> > >> that it gives us a stable pointer to serve as a hashmap key,
> > >> i.e. the identifier for
On 01/25, Junio C Hamano wrote:
> Brandon Williams writes:
>
> >> In my mind, the value of having a constant check_attr is primarily
> >> that it gives us a stable pointer to serve as a hashmap key,
> >> i.e. the identifier for each call site, in a later iteration.
> >
> > We
Brandon Williams writes:
>> In my mind, the value of having a constant check_attr is primarily
>> that it gives us a stable pointer to serve as a hashmap key,
>> i.e. the identifier for each call site, in a later iteration.
>
> We didn't really discuss this notion of having
On Wed, Jan 25, 2017 at 11:57 AM, Brandon Williams wrote:
> On 01/23, Junio C Hamano wrote:
>> Brandon Williams writes:
>>
>> > ... It seems like breaking the question and answer up
>> > doesn't buy you much in terms of reducing allocation churn and instead
On 01/23, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > ... It seems like breaking the question and answer up
> > doesn't buy you much in terms of reducing allocation churn and instead
> > complicates the API with needing to keep track of two structures instead
> > of
Brandon Williams writes:
> ... It seems like breaking the question and answer up
> doesn't buy you much in terms of reducing allocation churn and instead
> complicates the API with needing to keep track of two structures instead
> of a one.
In my mind, the value of having a
On 01/23, Brandon Williams wrote:
> As we discussed off-line I'll also do the rework to break up the
> question and result. That way two threads can be executing using the
> same attr_check structure.
Thinking about this I don't really see what we would gain by breaking
them up.
Right now most
On 01/23, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > The last big hurdle towards a thread-safe API for the attribute system
> > is the reliance on a global attribute stack that is modified during each
> > call into the attribute system.
>
> The same comment as
Brandon Williams writes:
> The last big hurdle towards a thread-safe API for the attribute system
> is the reliance on a global attribute stack that is modified during each
> call into the attribute system.
The same comment as 22/27 applies here.
It is not an immediate
The last big hurdle towards a thread-safe API for the attribute system
is the reliance on a global attribute stack that is modified during each
call into the attribute system.
This patch removes this global stack and instead a stack is stored
locally in each attr_check instance. This opens up
10 matches
Mail list logo