OK, merged :)
On Thu, Nov 7, 2013 at 5:10 PM, Felipe Farinon < [email protected]> wrote: > https://github.com/zeromq/libzmq/pull/742 > > Em 06/11/2013 11:14, Pieter Hintjens escreveu: > > Felipe, > > If you want to, please make a pull request with the change. > > Thanks > Pieter > > > On Wed, Nov 6, 2013 at 2:05 PM, Felipe Farinon < > [email protected]> wrote: > >> So, is there any interest in fixing this? >> >> >> -------- Mensagem original -------- Assunto: Re: [zeromq-dev] zmq_poll >> stops expiring timeout in virtualized Windows 7 Data: Tue, 29 Oct 2013 >> 10:19:08 -0200 De: Felipe Farinon >> <[email protected]><[email protected]> Responder >> a: ZeroMQ development list >> <[email protected]><[email protected]> Para: >> [email protected] >> >> >> We can make our own GetTickCount64 built around GetTickCount and call it >> when GetTickCount64 is not available in Kernel32.dll. This code supports >> Windows 2000 or greater, whereas calling GetTickCount64 directly from >> Kernel32.dll supports only Vista or greater. >> >> static DWORD s_wrap = 0; >> static DWORD s_lastTick = 0; >> static std::mutex s_wrapMutex; >> >> ULONGLONG MyGetTickCount64() >> { >> std::unique_lock<std::mutex>_(wrapMutex); >> DWORD currentTick = ::GetTickCount(); >> if (currentTick < s_lastTick) >> ++s_wrap; >> >> s_lastTick = currentTick; >> return (static_cast<ULONGLONG>(s_wrap) << 32) + currentTick; >> } >> >> >> Em 24/10/2013 16:19, Felipe Farinon escreveu: >> >> Unfortunately, GetTickCount64 is only supported on Windows Vista or >> greater. >> >> Em 21/10/2013 16:47, Felipe Farinon escreveu: >> >> GetTickCount64 would solve these problems, since it returns the numbers >> of millisenconds since the machine has started. >> >> Em 16/10/2013 12:47, Steven McCoy escreveu: >> >> On 16 October 2013 10:25, Laurent Alebarde <[email protected]> wrote: >> >>> A simplier approach is to encapsulate the standard clock of your >>> choice and save in a static member the value of the last get. Then if the >>> standard clock goes back in time, you return the saved value + 1. >>> >> >> For clock drift this is fine, one doesn't even have to bother with the >> increment for many cases. However there can be major problems with NTP, >> daylight savings, and suspend/hibernation states. >> >> -- >> Steve-o >> >> >> _______________________________________________ >> zeromq-dev mailing >> [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing >> [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing >> [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > > -- > - > Pieter Hintjens > CEO of iMatix.com > Founder of ZeroMQ community > blog: http://hintjens.com > > > _______________________________________________ > zeromq-dev mailing > [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
