[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #11 from Jonathan Wakely --- (In reply to Victor Mataré from comment #10) > OK, thanks for the clarification. But I feel I need to point out that that's > just a huge WTF. How is a C++ dev supposed to know from the standard docs > they work with all day that a condition_variable has any relation to > libpthread? You're not compiling with the standard, you're using GCC. The requirement to use libpthread is documented by the implementation (although it could be easier to find): https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #10 from Victor Mataré --- (In reply to Jonathan Wakely from comment #9) > The GNU libc has no-op stubs for several pthread functions. I think that is > done so that single threaded programs which don't actually need those > functions can still link to libraries that have references to those > functions. > > They don't block because they're not for use in multithreaded programs. If > you need the real versions you need to link to libpthread. OK, thanks for the clarification. But I feel I need to point out that that's just a huge WTF. How is a C++ dev supposed to know from the standard docs they work with all day that a condition_variable has any relation to libpthread? Least of all if you're used to getting linker errors if you're missing an implementation. I've read up on it a little bit and I can understand the rationale for having no-op mutex-related stuff because that doesn't break behavior in single-threaded code. But wait conditions are supposed to (mostly) block, single-threaded or not. A no-op stub is a severe breach of protocol there because no one expects to get "spurious" wakeups at 100% CPU. Just think about something like this happening in a real-time system. Maybe this should rather be a glibc bug. Any opinions on that?
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #9 from Jonathan Wakely --- The GNU libc has no-op stubs for several pthread functions. I think that is done so that single threaded programs which don't actually need those functions can still link to libraries that have references to those functions. They don't block because they're not for use in multithreaded programs. If you need the real versions you need to link to libpthread.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 Victor Mataré changed: What|Removed |Added CC||mat...@fh-aachen.de --- Comment #8 from Victor Mataré --- This has just caused me major headache because the behavior is completely unexpected. The root problem to me seems to be that pthread_cond_wait is defined not just in libphread, but also in libc: # objdump -TC /lib/libc.so.6 | grep cond_wait 0014a570 gDF .text 0033 (GLIBC_2.0) pthread_cond_wait 0007f5c0 gDF .text 0033 GLIBC_2.3.2 pthread_cond_wait Why is that even in there? And if I apparently end up calling this implementation, why doesn't block the way it should?
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- related to PR 55394
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I'm not really sure what we can do here. You need to use -pthread.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I suppose we could turn all timed waiting functions into sleeps, and wait() into an infinite loop, when libpthread is not linked in, but I'd prefer not to add that complexity.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #3 from Johan Lundberg lundberj at gmail dot com --- (In reply to Jonathan Wakely from comment #2) I suppose we could turn all timed waiting functions into sleeps, and wait() into an infinite loop, when libpthread is not linked in, but I'd prefer not to add that complexity. I agree, that sounds too much. The documentation of -pthread states that it sets flags for the preprocessor in addition to the linker and at least on my system, _REENTRANT is set by -pthreads. If that's a canonical way to detect threading support I suggest checking it in the headers that rely on threading: #ifndef _REENTRANT #error No thread support enabled. #endif If there are reasons this is not a good idea so be it.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- I don't think -pthread sets _REENTRANT for all targets, although it might do for all those where we actually support std::condition_variable.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Also, some people compile without -pthread then link with -lpthread manually. We could say that's technically unsupported, but currently it works.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- I'd say most people compile with -lpthread, I think glibc only keyes a single prototype on _REENTRANT (getlogin_r) and even that is also enabled by POSIX 1995 feature test macro too (which is on by default). So, conditionalizing something on _REENTRANT sounds a wrong idea to me.
