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

Laurent Alebarde l.alebarde at free.fr
Wed Oct 16 16:25:50 CEST 2013


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.

Le 16/10/2013 16:19, Bjorn Reese a écrit :
> On 10/16/2013 03:57 PM, Steven McCoy wrote:
>> On 16 October 2013 06:11, Bjorn Reese <breese at mail1.stofanet.dk
>> <mailto:breese at mail1.stofanet.dk>> wrote:
>>
>>      Alternatively, we could upgrade to C++11 and get a portable solution
>>      with std::chrono::steady_clock
>>
>>
>> Ok, here you go: "/a steady clock is not necessarily monotonic/".
>>
>> https://svn.boost.org/trac/boost/ticket/7719
> I was suggesting std::chrono, but boost::chrono. However, there appears
> to be a problem with std::chrono::steady_clock for MSVC:
>
> http://connect.microsoft.com/VisualStudio/feedback/details/753115/steady-clock-class-and-clock-function-are-non-conformant-with-c-11-and-c11-standards
>
> A workaround for this (and indeed for all the other alternatives
> suggested in this thread) is to create our own wrapper that handles
> the missing monotonicity with a modified Lamport timestamp.
>
> The idea is to maintain an offset that will be added to the clock when
> calling now(). Whenever the clock goes back in time, the offset is
> increased accordingly. That should be sufficient to guarantee a
> monotonic clock regardless of the underlying clock.
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131016/7139a443/attachment.htm>


More information about the zeromq-dev mailing list