llvm dev - Sep 2014 - [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> <atomic> should work both in win32 and pthread versions of MinGW.
<mutex> and <thread> are only supported in the pthread version
though.
<atomic> is trivial, as most of the support is provided by the compiler. 
As of Vista, Windows comes with some quite sane primitives for implementing
<mutex> and <thread>, so it would only be 1-2 days of work for
someone to write the implementation for libc++.

I'd suggest that the total effort that has gone into this thread so far is
close to the amount of effort required to add the missing support...

David

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:
> <atomic> is trivial, as most of the support is provided by the
> compiler. As of Vista, Windows comes with some quite sane primitives
> for implementing <mutex> and <thread>, so it would only be 1-2
days of
> work for someone to write the implementation for libc++.
Forcing Clang to depend on libc++ makes things quite complicated for the
end user. For the Windows case, building Clang without cross-compiling
could be impossible, if it requires that libc++ must be compiled by
Clang.

Also, can't we simply provide some dummy <mutex> / <thread> on
mingw
systems and warn loudly about single-threaded stuff?

This was a precedent actually - when LLVM started to use atomics,
everyone w/o them ended with non-reentrant LLVM and everything was ok.

On Wed, Sep 24, 2014 at 7:00 PM, David Chisnall
<David.Chisnall at cl.cam.ac.uk> wrote:
> On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>
>> <atomic> should work both in win32 and pthread versions of MinGW.
<mutex> and <thread> are only supported in the pthread version
though.
>
> <atomic> is trivial, as most of the support is provided by the
compiler.  As of Vista, Windows comes with some quite sane primitives for
implementing <mutex> and <thread>, so it would only be 1-2 days of
work for someone to write the implementation for libc++.
>
> I'd suggest that the total effort that has gone into this thread so far
is close to the amount of effort required to add the missing support...
>
> David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 9/24/14 10:20 AM, Anton Korobeynikov wrote:
> Also, can't we simply provide some dummy <mutex> / <thread>
on mingw
> systems and warn loudly about single-threaded stuff?
<mutex> shouldn't be too painful to have a single-threaded shim for.
<thread>
and <future> on the other hand seemed like a bit of a nightmare when I
looked at
them for the LIBCPP_HAS_NO_THREADS work. It might be good for someone else to 
look into it and give their opinion.


Cheers,

Jon
>
> This was a precedent actually - when LLVM started to use atomics,
> everyone w/o them ended with non-reentrant LLVM and everything was ok.
>
> On Wed, Sep 24, 2014 at 7:00 PM, David Chisnall
> <David.Chisnall at cl.cam.ac.uk> wrote:
>> On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>>
>>> <atomic> should work both in win32 and pthread versions of
MinGW. <mutex> and <thread> are only supported in the pthread
version though.
>>
>> <atomic> is trivial, as most of the support is provided by the
compiler.  As of Vista, Windows comes with some quite sane primitives for
implementing <mutex> and <thread>, so it would only be 1-2 days of
work for someone to write the implementation for libc++.
>>
>> I'd suggest that the total effort that has gone into this thread so
far is close to the amount of effort required to add the missing support...
>>
>> David
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On Wed, Sep 24, 2014 at 8:48 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:
>
> > <atomic> is trivial, as most of the support is provided by the
> > compiler. As of Vista, Windows comes with some quite sane primitives
> > for implementing <mutex> and <thread>, so it would only be
1-2 days of
> > work for someone to write the implementation for libc++.
>
> Forcing Clang to depend on libc++ makes things quite complicated for the
> end user. For the Windows case, building Clang without cross-compiling
> could be impossible, if it requires that libc++ must be compiled by
> Clang.

The only way Clang would depend on libc++ is if you weren't able or willing
to use one of the other host toolchains to cross to windows. Both mingw-w64
and the threads-posix stuff which supports C++11 <thread> would work fine
as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/5d3ee1ce/attachment.html>

On Wed, Sep 24, 2014 at 9:20 AM, Anton Korobeynikov <anton at
korobeynikov.info
> wrote:
> Also, can't we simply provide some dummy <mutex> / <thread>
on mingw
> systems and warn loudly about single-threaded stuff?
>
I think it's a mistake. It becomes really hard to say we "support"
a
platform when the user will have to hold LLVM just right in order to use it
correctly. =/

It also means we have to carry a bunch of "portability" cruft in LLVM.
These are not small or simple headers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/b06f05e5/attachment.html>