> I don't see why it has to be a struct, it just has to be suitable as
> an argument to the relevant __gthread functions.
The type __gthread_time_t is referenced in
gcc/libstdc++-v3/include/std/mutex:157
__gthread_time_t __ts = {
static_cast<std::time_t>(__s.time_since_epoch().count()),
static_cast<long>(__ns.count())
};
This definition uses a braced-init-list that has two elements and is unsuitable
for scalar types.
> If the current code assumes a struct and the Windows API calls need an
> integer then either the existing code needs to be made more flexible,
> or you need to define it as a struct and then convert to an integer
> inside your new gthread wrapper functions.
The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer and
an array of two 32-bit integers - because some languages might have no native
64-bit integer types.
Actually in C99 and C++11 we just assume there is long long and int64_t despite
the fact that ISO C marks int64_t as optional, so it can be regarded as a union
whose only element is an int64_t.
> std::condition_variable::__clock_t must be a typedef for the clock
> used by the underlying implementation, so it sounds like you should
> use std::chrono::steady_clock for your thread model.
> All conversions are done using the std::chrono facilities, before any
> conversion to __gthread_time_t. That means the conversions are
> portable.
Thought so. I have to take a deep look.
Thanks for your help!
------------------
Best regards,
lh_mouse
2016-04-18
