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

Justin Cook jhcook at gmail.com
Tue Oct 15 21:08:39 CEST 2013


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






More information about the zeromq-dev mailing list