> On Apr 5, 2017, at 2:22 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > > My reasoning is rather that we implement a generic pshared condvar > solution (like we do for thread-mutexes), and if it does not work on > OSX (because for some reasons their condvar does not work as > advertised or in any sane manner), well, let them responsible for > their bugs.
Can this generic pshared condvar be used no matter WHAT serialize an OS has? The point is that anything under "unix" is assumed to be pthread, not posix-sem and not sysv-sem because, if that was NOT the case, this would have been more an issue earlier, since other unix-like systems would have been affected. So saying we have a work-around for pthread_mutex_trylock() and only pthread_mutex_trylock() isn't enough. If we have a *better* impl for pthread_mutex_trylock() that what is in there now, great, but we can't short change those platforms that use posix-sem or sysv-sem or, even worse, those that specifically BUILD their systems to USE these semaphore/lock mechanisms. As such, we have no idea how well this works posix-sem or sysv-sem... we assume OK, but from what I can tell no one has ever tickled that codepath because everyone gets/uses pthreads. The assumption that "it's been in trunk" should be enough to warrant inclusion isn't quite valid... once we start considering *releasing* the code, then we need to look at the new stuff and consider if it is really ready for prime time. Instead, we have something that was sitting for a year, but never used, and thus never exercised, and what limited testing there was, just tested/exercised a single impl out of 3 for our main platform, "unix".
