Hi, Sergey!
On Feb 28, Sergey Vojtovich wrote:
> Hi Sergei,
>
> indeed, but that's only for -DBUILD_CONFIG=mysql_release or explicit
> -DWITH_FAST_MUTEXES=ON. I though it should be enabled by
> -DCMAKE_BUILD_TYPE=Release (the way I was attempting to get it).
We build release binaries (I believe)
Hi Sergei,
indeed, but that's only for -DBUILD_CONFIG=mysql_release or explicit
-DWITH_FAST_MUTEXES=ON. I though it should be enabled by
-DCMAKE_BUILD_TYPE=Release (the way I was attempting to get it).
Ok, I'll disable it in 5.5.
Thanks,
Sergey
On Fri, Feb 28, 2014 at 09:52:00AM +0100, Sergei G
Hi, Sergey!
On Feb 27, Sergey Vojtovich wrote:
> Hi Sergei,
>
> do you know if we ship any binaries with fast mutex (-DMY_PTHREAD_FASTMUTEX)
> enabled or officially suggest it? What was it's intention and what loads it
> was
> supposed to make faster?
As far as I understand, we built with fastm
Hi Davi,
thanks for this information, it is really useful.
According to bzr history fast mutex was added back in 2005. I have a few
guesses why it would have been needed:
- probably at that time mutex implementation wasn't as good as it is now
- probably mutex implementation on some specific plat
Hi Sergey,
I looked into fast mutex in the past [1] and was never able to get a
straight answer (even from the original developer) on what was the
intention behind it and how it made things faster as it actually made
things slower in the past (Bug#38941, others). There is a comment in
http://bugs.
Hi Sergei,
do you know if we ship any binaries with fast mutex (-DMY_PTHREAD_FASTMUTEX)
enabled or officially suggest it? What was it's intention and what loads it was
supposed to make faster?
I'm trying to understand if fastmutex is worth fixing. It looks like duplication
of PTHREAD_MUTEX_ADAPTI
6 matches
Mail list logo
