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

[Felipe Farinon]

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: 
http://pastebin.com/Umyt9Hsy
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