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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Oct 27, 2016, 21:49 UTC
Message-ID: <CA+P7+xpckfaeHmoEGQBdLD-=Kf7gQ-jOxGFKrKmiFH1SBN7GjA@mail.gmail.com>
In-Reply-To: <a2e5acd6-485d-0387-7a85-6042dee702f7@kdbg.org>

On Thu, Oct 27, 2016 at 1:05 PM, Johannes Sixt <j6t@kdbg.org> wrote:

Show 11 quoted lines

>> 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 else, too). But time is much
> better spent on an attr_start() solution.
>
> -- Hannes
>

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 penalizes Windows too much" but... If Windows cannot statically initialize a pthread mutex, then we *have* to dynamically initialize it somewhere. This solution adds a single check before each lock and is safe due to use of memory barriers. Yes, this will cost a tiny bit extra overhead for each use of "pthread_mutex_lock" but I fail to see how that is a huge penalty...

So I'm trying to understand if that really is your only concern, because I don't actually buy that it is a huge overhead to pay.

I agree with Stefan that there isn't really a great place to put a dynamic initialization.

To be clear I am trying to understand the objections since so far all I have read is "this is bad, and I object" without clearly explaining reasoning.

Regards, Jake