[zeromq-dev] Fwd: Re: zmq_poll stops expiring timeout in virtualized Windows 7

Pieter Hintjens ph at imatix.com
Wed Nov 6 14:14:46 CET 2013


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 <
felipe.farinon at powersyslab.com> 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 <felipe.farinon at powersyslab.com><felipe.farinon at powersyslab.com>  Responder
> a: ZeroMQ development list <zeromq-dev at lists.zeromq.org><zeromq-dev at lists.zeromq.org>  Para:
> zeromq-dev at lists.zeromq.org
>
>
> 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 <l.alebarde at free.fr> 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 listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> _______________________________________________
> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> _______________________________________________
> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131106/645d90ec/attachment.html>


More information about the zeromq-dev mailing list