Hi, Teodor!
I'd just say that this MutexDebug thing relies on pthread_t being
ulint.
So, I'd add a test to innodb.cmake, like, PTHREAD_T_IS_ULINT or detected
that by the compiler in sync0policy.h. And only compiled MutexDebug is
pthread_t is ulint. Or, at least, sizeof(pthread_t) == sizeof(ulint).
On Apr 16, Teodor Mircea Ionita wrote:
> Hi,
>
> While trying to build on macOS 10.13.4 with clang 9.1.0 I originally came
> across this error:
> --
> .../storage/innobase/include/sync0policy.h:79:4: error: cannot initialize a
> parameter of type 'int64' (aka 'long long') with
> an rvalue of type 'os_thread_id_t' (aka '_opaque_pthread_t *')
> my_atomic_storelint(&m_thread_id,
> os_thread_get_curr_id());
> ---
> This problem was originally reported in MDEV-15778. Since pthread_t on macOS
> is a pointer to a struct named _opaque_pthread_t, the "obvious" solution for
> this was to explicitly cast to ULINT which in turn is defined as size_t, fine
> so far. Solution was tested in PR#691.
>
> However, upon testing my patch with buildbot, on slave kvm-fulltest2, which
> is 64bit qemu vm with Ubuntu precise-i386 (32bit) running and gcc compiling
> in -march=i686. The above "fix" now yields:
> --
> /home/buildbot/buildbot/build/mariadb-10.3.6/storage/innobase/include/sync0policy.h:79:4:
> error: invalid cast from type ‘os_thread_id_t {aka long unsigned int}’ to
> type ‘ulint {aka unsigned int}’
> ---
>
> Now reconsidering more carefully, this looks more serious then initially
> thought, posix pthread_t(3) is defined as:
> --
> POSIX.1 allows an implementation wide freedom in choosing the type used to
> represent a thread ID; for example, representation using either an arithmetic
> type or a structure is permitted. Therefore, variables of type pthread_t
> can't portably be compared using the C equality operator (==); use
> pthread_equal(3)instead.
> ---
>
> So in this particular platform spec, where pthread_t on Linux is defined as
> unsigned long int integral type and if LP64 model is used, this implies
> pthread_t always being 64bit in either both 32 and 64 arch and trying to
> convert to size_t on a 32bit arch will fail.
>
> Now given that the standard particularly states pthread_t as being opaque and
> no assumptions should be made in regards to the actual type, not even an
> initializer type (which ULINT_UNDEFINED defines as -1), trying to cast
> m_thread_id to any other type ( (ULINT) ) either implicitly or explicit is
> not portable. Is this a bug that needs fixing or just impossible to handle
> pthread id atomically in any other fashion? How about a test case I can run
> to confirm/infirm erratic behavior?
>
> Since I don't have access to the particular bb slave instance to check with
> sizeof() maybe somebody else can help me here to confirm this? Relevant links
> bellow:
>
> https://jira.mariadb.org/browse/MDEV-15778
> https://buildbot.askmonty.org/buildbot/builders/kvm-fulltest2/builds/12317/steps/compile/logs/stdio
> https://linux.die.net/man/3/pthread_self
> https://github.com/MariaDB/server/pull/691
>
> Cheers,
> Teodor
Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
