This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Re: Adding a new thread model to GCC


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]