On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano <gits...@pobox.com> wrote: > Johannes Sixt <j...@kdbg.org> 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 >> ballpark as an uncontended mutex. I'm not enthused. >> >>> The positive aspect of this way the patch proposes would be that any >>> future contributor not knowing the details of how to do mutexes right >>> on Windows, would not totally break the whole system, i.e. this seems >>> to be more maintainable in the future as it reduces the friction between >>> pthreads mutexes and the way we can do things in Git in a platform >>> independent way >> >> This is a non-argument. Coders have to know their tools.
Windows is not my tool. > > The codebase should strive to give coders a coherent abstraction > that can be implemented efficiently on platforms, so that coders do > not have to care too deeply about quirks that exist on individual > platforms. Currently working as a coder I care about "submodules, that work on linux." I do not care about Windows in the big picture. I am however willing to go an extra step to not break Windows. However that requires a little bit of effort from both me and you: * I need to be aware of what I cannot do with "not-my-tools". (So please somebody tell me, also in the future when I break obscure platforms. Mind that I don't equate obscure with not widely used or in any other way negative. It's just that people working on linux find some quirks on Windows not "obvious") * the workaround should not be too time consuming in the bigger picture, which is why I propose to make the API a bit clearer by emulating posix mutexes harder. (From a Windows POV this might sound like making it more obscure because posix mutexes itself are obscure.) > > It is OK to argue that the particular solution Stefan lifted from > somewhere (perhaps msdn article he cited???) A stack overflow article that I found with my search engine of choice, because I could not believe that Windows cannot have statically initialized mutexes. > does not qualify as > such an abstraction. The implementation under discussion (well we did not discuss the implementation a whole lot yet) may even contain an error as the first memory barrier needs to be in front of the first condition. > But I do not agree with your "Coders have to > know" as a blanket statement. Well I do to some extent, I just disagree what my tools are.
