Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-25 Thread Brandon Williams
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-25 Thread Brandon Williams
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-25 Thread Junio C Hamano
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-25 Thread Stefan Beller
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-25 Thread Brandon Williams
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-23 Thread Junio C Hamano
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-23 Thread Brandon Williams
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-23 Thread Brandon Williams
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

Re: [PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-23 Thread Junio C Hamano
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

[PATCH v2 25/27] attr: store attribute stack in attr_check structure

2017-01-23 Thread Brandon Williams
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