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

Felipe Farinon felipe.farinon at powersyslab.com
Wed Oct 16 19:39:57 CEST 2013

The problem didn't occur with a Linux guest, at least not in the 1st 
hour of execution.

For anyone that wants to reproduce the problem, here's the code: 
When 'current.QuadPart' gets around 2943506487, zmq_poll freezes.

Em 15/10/2013 16:08, Justin Cook escreveu:
> This is a good find.
> In my humble opinion -- and since a lot of applications are moving to virtualised guests -- a low-resolution timer should be used by default. It would then be the call of the developer to explicitly decide otherwise.
> This is a genuine case of use worst case by default with the end user specifically specifying more granularity.
> The VirtualBox ticket was closed as invalid, and it was suggested that this is a Microsoft "issue". Is this something that should be changed by default only on Microsoft builds?
> Felipe, is this something you could try and reproduce with a Linux guest?
> --
> Justin Cook
> On Tuesday, 15 October 2013 at 19:49, Felipe Farinon wrote:
>> That seems a strange thing to do, since even Windows doesn't guarantee
>> the monotonicity of the timer used by QPC (e.g. when using ACPI timer).
>> If we want to cover the cases where Windows is using ACPI timer, even
>> outside of VirtualBox, we should make it possible to switch by default
>> to GetTickCount64. Note that if the ZeroMQ user doesn't use a small
>> timeout in zmq_poll, this shouldn't be a big penalty.
>> By the way, detecting that we're running inside a virtual machine is a
>> rather difficult process. Most techniques may lead to false positives.
>> Em 15/10/2013 15:26, Pieter Hintjens escreveu:
>>> Is there any way to detect at runtime that we're running in VirtualBox?
>>> On Tue, Oct 15, 2013 at 7:48 PM, Felipe Farinon
>>> <felipe.farinon at powersyslab.com (mailto:felipe.farinon at powersyslab.com)> wrote:
>>>> I´ve built an application that is running on a Windows 7 inside a
>>>> VirtualBox, with zeromq 3.2.2.
>>>> == The problem ==
>>>> When running one test, I noticed that my application called zmq_poll
>>>> with timeout of 2000 but it at one day stopped expiring the timeout.
>>>> Similarly, a client application that connected to it and had a loop that
>>>> used QueryPerformanceCounter for timeout, suddenly froze and stopped
>>>> firing the timeout. After doing some research, I have found that
>>>> VirtualBox's QueryPerformanceCounter doesn't guarantee monotonicity
>>>> https://www.virtualbox.org/ticket/11951. They argue that even Windows
>>>> QueryPerformanceCounter doesn't guarantee it.
>>>> Then I have found that zmq_poll calls clock_t::now_ms which in turn
>>>> calls clock_t::now_us which uses QueryPerformanceCounter.
>>>> == My proposal ==
>>>> We could add a zeromq define that makes zmq_poll use a low precision
>>>> timer, such as GetTickCount64 which has less bugs.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list