Re: [PATCH] compat: Allow static initializer for pthreads on Windows

From: Johannes Sixt <j6t@kdbg.org>
Date: Oct 28, 2016, 20:26 UTC
Message-ID: <38b70094-5550-8512-7735-a6739f435803@kdbg.org>
In-Reply-To: <CA+P7+xoyF8EG079eC-dfTSj+YrbxhPWx356-jZ90gDs6SwyppA@mail.gmail.com>

Am 28.10.2016 um 20:48 schrieb Jacob Keller:

Show 17 quoted lines

> On Fri, Oct 28, 2016 at 4:58 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> 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#L25-L41
>
> I think Stefan has since provided a better suggestion of isolating the
> dynamic initialization into the MINGW startup section. However, you
> are right either place works, though I think platforms which support
> static initialization should use it.

It's a pity that this new patch introduces the first use of PTHREAD_MUTEX_INITILIZER. (I do not count the one in compat/nedmalloc, it's in platform specific code.) We have to introduce a dummy definition on Windows to even compile the code.

Now we have a double-edged sword: Other coders who are not aware of this thread might think it works. But it does not.

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. However, it would not be a major offense to #include attr.h in common-main.c. But when we do that, we can certainly spare the few cycles to call pthread_mutex_init.

-- Hannes