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 *')
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:
 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 

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 


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

Reply via email to