Johannes Sixt writes:
> Am 28.10.2016 um 22:29 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> Another problem with the proposed patch is that there is no
>>> declaration for attr_start() before the call in compat/mingw.c. We
>>> would have to move the declaration of attr_start() to cach
Am 28.10.2016 um 22:29 schrieb Junio C Hamano:
Johannes Sixt writes:
Another problem with the proposed patch is that there is no
declaration for attr_start() before the call in compat/mingw.c. We
would have to move the declaration of attr_start() to cache.h (for
example), because #including at
Stefan Beller writes:
> On Fri, Oct 28, 2016 at 1:29 PM, Junio C Hamano wrote:
>> Johannes Sixt writes:
>>
>>> Another problem with the proposed patch is that there is no
>>> declaration for attr_start() before the call in compat/mingw.c. We
>>> would have to move the declaration of attr_start(
On Fri, Oct 28, 2016 at 1:29 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Another problem with the proposed patch is that there is no
>> declaration for attr_start() before the call in compat/mingw.c. We
>> would have to move the declaration of attr_start() to cache.h (for
>> example),
Johannes Sixt writes:
> Another problem with the proposed patch is that there is no
> declaration for attr_start() before the call in compat/mingw.c. We
> would have to move the declaration of attr_start() to cache.h (for
> example), because #including attr.h in compat/mingw.c is plainly
> wrong.
Am 28.10.2016 um 20:48 schrieb Jacob Keller:
On Fri, Oct 28, 2016 at 4:58 AM, Johannes Schindelin
wrote:
Hi Jake,
On Thu, 27 Oct 2016, Jacob Keller wrote:
I agree with Stefan that there isn't really a great place to put a
dynamic initialization.
Ummm. Wait. What???
https://github.com/git/
On Fri, Oct 28, 2016 at 6:01 AM, Philip Oakley wrote:
> From: "Johannes Sixt"
>>
>>
>> One point is that the DCLP idiom must be implemented correctly. There are
>> solutions, of course, and when the initialization is over, we have a
>> miniscule overhead at each pthread_mutex_lock call.
>>
>
> I
On Fri, Oct 28, 2016 at 4:58 AM, Johannes Schindelin
wrote:
> Hi Jake,
>
> On Thu, 27 Oct 2016, Jacob Keller wrote:
>
>> I agree with Stefan that there isn't really a great place to put a
>> dynamic initialization.
>
> Ummm. Wait. What???
>
> https://github.com/git/git/blob/v2.10.1/common-main.c#L
From: "Johannes Sixt"
One point is that the DCLP idiom must be implemented correctly. There are
solutions, of course, and when the initialization is over, we have a
miniscule overhead at each pthread_mutex_lock call.
I had to look up DCLP ( = Double Checked Locking Patterns), and found a
Hi Jake,
On Thu, 27 Oct 2016, Jacob Keller wrote:
> I agree with Stefan that there isn't really a great place to put a
> dynamic initialization.
Ummm. Wait. What???
https://github.com/git/git/blob/v2.10.1/common-main.c#L25-L41
Ciao,
Johannes
On Thu, Oct 27, 2016 at 10:55 PM, Johannes Sixt wrote:
> One point is that the DCLP idiom must be implemented correctly. There are
> solutions, of course, and when the initialization is over, we have a
> miniscule overhead at each pthread_mutex_lock call.
>
Right, this I understood, but appeared
Am 27.10.2016 um 23:49 schrieb Jacob Keller:
Ok, so I've been reading this thread. I don't understand your
objections to emulating in this way.. Could you clearly spell out why
you believe this solution isn't acceptable? So far all I've understood
was "it's not critical sections" and "it penalize
> there isn't really a great place to put a dynamic initialization.
Answering this question specifically (Where to put it?),
I am about to send out a patch that puts it in compat/mingw.c:2232:
diff --git a/compat/mingw.c b/compat/mingw.c
index 3fbfda5..9881c3d 100644
--- a/compat/mingw.c
+++ b/co
On Thu, Oct 27, 2016 at 1:05 PM, Johannes Sixt wrote:
>> The implementation under discussion (well we did not discuss the
>> implementation a
>> whole lot yet) ...
>
>
> There's not a whole lot to discuss: it must be rewritten from scratch (it's
> not just the memory barriers, it is everything els
Am 27.10.2016 um 21:08 schrieb Stefan Beller:
On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote:
Johannes Sixt writes:
Am 27.10.2016 um 19:01 schrieb Stefan Beller:
...
It is not possible to mark a mutex uninitialized on Windows without an
extra piece of data. A solution would become qu
On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Am 27.10.2016 um 19:01 schrieb Stefan Beller:
>> ...
>> It is not possible to mark a mutex uninitialized on Windows without an
>> extra piece of data. A solution would become quite complicated quite
>> quickly, a
Johannes Sixt writes:
> Am 27.10.2016 um 19:01 schrieb Stefan Beller:
> ...
> It is not possible to mark a mutex uninitialized on Windows without an
> extra piece of data. A solution would become quite complicated quite
> quickly, and at the cost of additional operations that are in the same
> ba
Am 27.10.2016 um 19:01 schrieb Stefan Beller:
Johannes Sixt writes:
This is the pessimization that I am talking about. I would not mind at all if
it were only for the attribute subsystem, but the proposed patch would
pessimize *all* uses of pthread_mutex_lock.
It would only pessimize *uninitia
On Thu, Oct 27, 2016 at 10:01:02AM -0700, Stefan Beller wrote:
> > That function can
> > be called from main() of platforms that cannot statically initialize
> > mutices,
>
> By main you mean the main() in common-main.c or cmd_main in git.c ?
Any setup or initialization for library functions ne
> Johannes Sixt writes:
> This is the pessimization that I am talking about. I would not mind at all if
> it were only for the attribute subsystem, but the proposed patch would
> pessimize *all* uses of pthread_mutex_lock.
It would only pessimize *uninitialized* mutexes? For initialized mutexes
t
Junio C Hamano writes:
> Johannes Sixt writes:
>
>>> As many codepaths may not even need access to the attributes, I
>>> doubt that would be a very productive direction to go.
>>
>> So, what is productive then? Pessimizing one (not exactly minor) platform?
>
> Lazy on-demand initialization as ne
Am 27.10.2016 um 08:21 schrieb Junio C Hamano:
Johannes Sixt writes:
As many codepaths may not even need access to the attributes, I
doubt that would be a very productive direction to go.
So, what is productive then? Pessimizing one (not exactly minor) platform?
Lazy on-demand initializati
Johannes Sixt writes:
>> As many codepaths may not even need access to the attributes, I
>> doubt that would be a very productive direction to go.
>
> So, what is productive then? Pessimizing one (not exactly minor) platform?
Lazy on-demand initialization as needed, perhaps? The on-demand
initi
Am 27.10.2016 um 08:02 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 26.10.2016 um 23:57 schrieb Stefan Beller:
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no go
Johannes Sixt writes:
> Am 26.10.2016 um 23:57 schrieb Stefan Beller:
>> In Windows it is not possible to have a static initialized mutex as of
>> now, but that seems to be painful for the upcoming refactoring of the
>> attribute subsystem, as we have no good place to put the initialization
>> of
Am 26.10.2016 um 23:57 schrieb Stefan Beller:
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no good place to put the initialization
of the attr global lock.
Please rewr
On Wed, Oct 26, 2016 at 2:57 PM, Stefan Beller wrote:
> In Windows it is not possible to have a static initialized mutex as of
> now, but that seems to be painful for the upcoming refactoring of the
> attribute subsystem, as we have no good place to put the initialization
> of the attr global lock
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no good place to put the initialization
of the attr global lock.
The trick is to get a named mutex as CreateMutex[1] will ret
28 matches
Mail list logo
