I picked the name to match the one I recently added to libc++abi. I'm open to suggestions though.
The other one I considered was _LIBCPP_HAS_POSIX_THREADS, but that seemed to be less fitting (one could have a system with pthreads, but still not want to build libc++ with threads enabled, for example).
|124 ↗||(On Diff #9964)|
Is there much of a precedent either way? I haven't seen any laid out like that...
In general, libc++ uses the negative for missing capabilities.
I would prefer to keep this convention.
I would also like to understand more about the motivation behind this patch.
Concurrency is a core part of C++11library, and just disabling it seems wrong to me.
I know there are systems w/o POSIX threads, but to support those systems, libc++ should use whatever primitives exist there, rather than just disabling all the threading support.
What are you trying to accomplish here?
mclow, the motivation for this is for bare-metal systems where we don't have threads. I suppose my title for this left a little too much room to read into it.
The other alternative would be to write no-op shims around all of these primitives, but that seems like it would be a lot of mess for very little benefit.
|419 ↗||(On Diff #9964)|
line should read:
#endif // !_LIBCPP_SINGLE_THREADED
|175 ↗||(On Diff #9964)|
line should read:
#endif // __has_feature(cxx_atomic) && !_LIBCPP_SINGLE_THREADED
See the inline comments; I think that _LIBCPP_HAS_NO_THREADS should be defined when building single-threaded, and not defined otherwise (that would match the rest of the libc++ config macros).
Also, aren't there a bunch of tests that are going to need to change?
This should be wrapped in an "#ifndef _LIBCPP_HAS_NO_THREADS" block, and should just define it, rather than give it a 0/1 value.
This will allow someone to build an "no threads" version of libcpp by -D _LIBCPP_HAS_NO_THREADS on the command line.
this should just be #ifndef _LIBCPP_HAS_NO_THREADS
I have another set of patches for the tests that this affects. Should I merge them all and include them here?
Wait, do you mean that this hunk should just go away? Or do you mean that it should be:
#if !defined(_LIBCPP_HAS_NO_THREADS) && defined(_POSIX_THREADS) && _POSIX_THREADS > 0 #define _LIBCPP_HAS_NO_THREADS #endif
I'm not sure I understand what you're asking for here.
Ok, I'll change all of them to that style.
Looks like... I'll get rid of it.
It'll take a bit more to fish out the changes to the tests (mostly adding 'XFAIL: libcxx-single-threaded')
@mclow earlier you suggested having just the build define this with -D_LIBCPP_HAS_NO_THREADS. I thought adding this as a error/warning might be nice.
Another thing I've just realized: if this is only set during the build, then how to I arrange for it to be set in an installed system? I don't want my users to have to -D_LIBCPP_HAS_NO_THREADS whenever they want to use libcxx.
s/system/single threaded system/
un-necessary whitespace change
|615 ↗||(On Diff #12804)|
I missed a pair of changes in this file. The __has_feature(cxx_atomic) #ifdef block needs to be:
#if __has_feature(cxx_atomic) && !defined(_LIBCXX_HAS_NO_THREADS) ... #endif // __has_feature(cxx_atomic) && !defined(_LIBCXX_HAS_NO_THREADS)
I also missed a pair of these in include/ios near lines 216 and 367
I'm a little bit worried about the no-threads build bit-rotting (if any of us forget to wrap something in #ifndef _LIBCPP_HAS_NO_THREADS). Should we have a buildbot set up to build this configuration? Would it be possible to define noop implementations of all the things you've ifdef'd out so that we don't have to worry about that? It's possible that would make things more or a mess, but I'm not sure.
From email thread:
Should we have a buildbot set up to build this configuration?
I would appreciate having one, but I can't host it at the moment.
At some point I would like to host a baremetal buildbot (targeting either QEMU, a raspberry pi, or some beagleboard), but I'm not quite ready for that... we need to work out the details of remote testing in lit before that is practical.
Keeping a buildbot going for this patch doesn't actually require baremetal (though that would be nice to have as well). @EricWF recently set up a buildbot. He might be willing to host it.
Would it be possible to define noop implementations of all the things you've ifdef'd out so that we don't have to worry about that? It's possible that would make things more or a mess, but I'm not sure.
I think that nop-shims have an even higher potential for bit-rot than these #ifdef's.
I originally attempted writing no-op shims for a few of them, but there were several where it didn't seem possible, and others where the shims were pretty hairy.
Okay, I thought that might be the case.
With those things accounted for, LGTM.