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 >>> <[email protected] (mailto:[email protected])> >>> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
