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

[Felipe Farinon]

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> 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
>
>