[PATCH] Change base mutex implementations to use STL-provided mutexes

Zachary Turner zturner at google.com
Fri Jun 6 13:15:21 PDT 2014


It's definitely possible, it's just a lot of work.  But it can be done in a
way that is low maintenance and actually *increases* portability and code
maintainability, in my opinion.  Chrome does it for example, and that is a
pretty large project.  Either way, it's independent of this particular
change, so I will fight that battle another time :)


On Fri, Jun 6, 2014 at 1:10 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

>
> On Fri, Jun 6, 2014 at 12:32 PM, Alp Toker <alp at nuanti.com> wrote:
>
>> Hi Zachary,
>>
>> In LLVM platform-specific code goes in the implementation files (.inc)
>> and never in the portable headers. Certainly for a high-level class like
>> Mutex I wouldn't expect to see platform-specific conditionals exposed.
>>
>> A couple of exceptions have slipped in like Support/FileSystem.h and
>> Support/Process.h with ifdef WIN32 but those are meant to get fixed at some
>> point.
>>
>
> While you may be describing the current situation, I don't think that this
> is really a strong rule than many LLVM developers feel constrained by, and
> I wouldn't want it to be.
>
> I think the important rule is subtly but importantly different: the header
> files must, ultimately, be portable. Where possible, it is useful to
> isolate platform specific code away from header files, but it is not always
> possible or desirable. Either way, the header file needs to carefully
> manage any platform specifics involved to ensure it works correctly and
> reliably across platforms.
>
> One example of this (but not necessarily a *good* example -- I would use a
> different technique) is our DataTypes.h which is generated at
> configure/cmake time.
>
> I think it is entirely possible that the correct thing to do for some
> parts of Support is to include windows.h with appropriate control of macros
> and behind appropriate guards. I say it is "possible" because I don't know
> very much about the *specific* case of windows.h and its problems. Perhaps
> there are specific problems with it that make it intractable to use in this
> way even on Windows. But the general concept seems fine when useful.
> Similarly, if we wanted to include a Mac OS X header file to access a
> synchronization or other primitive provided by the OS, it would seem
> reasonable to include that header, again provided sufficient care and
> guards are used to make sure the header, as a whole, remains a reliable
> header for other projects to use on each platform.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140606/6102c353/attachment.html>


More information about the llvm-commits mailing list