Talk specifically about C++ std::timed_mutex:
From ISO/IEC WG21 Draft N4582 (C++1z)
[quote]
30.4.1.3.1 Class timed_mutex [thread.timedmutex.class]
...
template
bool try_lock_for(const chrono::duration& rel_time);
template
bool try_lock_until(const chrono::time_point& abs_time);
...
[/quote]
Mer
Great job. Thanks a lot!
--
Best regards,
lh_mouse
2016-04-15
-
发件人：Alexpux
发送日期：2016-04-15 01:33
收件人：lh_mouse
抄送：mingw-w64-public,Msys2
主题：Re: [Msys2-users] [Mingw-w64-public] Where can I
> 14 апр. 2016 г., в 20:07, lh_mouse написал(а):
>
> Oh the attachment was filtered out because it was too big. Compressed and
> uploaded again.
>
> --
> Best regards,
> lh_mouse
> 2016-04-15
>
>
Oh the attachment was filtered out because it was too big. Compressed and
uploaded again.
--
Best regards,
lh_mouse
2016-04-15
-
发件人："lh_mouse"
发送日期：2016-04-15 01:04
收件人：mingw-w64-public,Ms
I am trying compiling GCC unpatched from git HEAD and have encountered some
cryptic errors.
In stage 2 the newly built compiler, xgcc, is unable to find any system headers
because no proper -isystem or -I is given. (I have attached the config.log to
this mail. It was in /gmp/.)
Kai suggested th
On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being
> compatible with very old Windows versions, also having a number of drawbacks:
> 0) its implementation is very inefficient, and
> 1) its mutexes and cond
On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8
> and later.
Yes. On Windows 8, given
Hello,
current implementaion of pthread_cleanup_pop does not compile under gcc
5.3.0.
See line 214 in pthread.h (
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/include/pthread.h
):
#define pthread_cleanup_pop(E)\
(*pthread_getclean() = _pthread_cup.
On Thu, Apr 14, 2016, lh_mouse wrote:
> C++0x threading APIs are currently unimplemented.
>
> It is only because gthr.h is so obscure about __gthred_time_t.
> It doesn't say anything about whether __gthread_time_t should be a struct
> (like struct timespec) or a plain integer or even a floating p
Something about replacing winpthread:
If mcfgthread is loaded as a dynamic library, everything is fine. Its DllMain()
function gets a DLL_THREAD_DETACH notification upon thread exit, enabling
cleanup of thread local storage.
However if you wish to link mcfgthread statically, there will be troub
C++0x threading APIs are currently unimplemented.
It is only because gthr.h is so obscure about __gthred_time_t.
It doesn't say anything about whether __gthread_time_t should be a struct (like
struct timespec) or a plain integer or even a floating point type, neither does
it say where and how to
Maybe we misunderstand each other?
I understood your question as a proposal to make -D_WIN32_WINNT=xy imply
also implicitly some --enable-threads=xy. That would be a problem, because
semantics of -D_WIN32_WINNT=xy should imho have no implication on chosen
run time, but just on what's made availab
I'd really really really suggest just using --enable-threads=windows or
something, and implement them using somthing compatible to the windows
runtime if at all possible. This is available on Windows 7+ and seems as
reasonable as anything.
If there are better routines in e.g. Windows 8 or 10, it w
If we use --enable-threads=win32-win7 , the result gcc running on and
target to win7 or later looks reasonable.
On Thu, Apr 14, 2016 at 2:34 PM, Martin Mitáš wrote:
>
>
> Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
>> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>
14 matches
Mail list logo
