On 18 April 2016 at 10:18, lh_mouse wrote:
>> 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.
Yes I know.
What I meant is that there's no fundamental reason it needs to be a
struct. That code could be changed.
>> 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.
What are the units of the argument? Milliseconds?
You have two choices, either modify all the places in libstdc++ that
use __gthread_time_t, changing the code to use some new function
template that populates a __gthread_time_t from a
std::chrono::time_point<C,D> or std::chrono::duration<R,P>, or define
a similar struct in your gthreads header and convert it to int64_t
inside your functions. For functions taking a relative time the
conversion from a { seconds, nanoseconds } struct to milliseconds is
trivial, for functions taking an absolute time you need to know the
epoch of the clock that was used when populating the struct.
