Thank you. Could you backport it to 3.2.x, please?
It's nice to contribute for the first time. I hope I can help improving
zeromq's quality.
Em 07/11/2013 14:13, Pieter Hintjens escreveu:
OK, merged :)
On Thu, Nov 7, 2013 at 5:10 PM, Felipe Farinon
<[email protected]
<mailto:[email protected]>> wrote:
https://github.com/zeromq/libzmq/pull/742
Em 06/11/2013 11:14, Pieter Hintjens escreveu:
Felipe,
If you want to, please make a pull request with the change.
Thanks
Pieter
On Wed, Nov 6, 2013 at 2:05 PM, Felipe Farinon
<[email protected]
<mailto:[email protected]>> wrote:
So, is there any interest in fixing this?
-------- Mensagem original --------
Assunto: Re: [zeromq-dev] zmq_poll stops expiring timeout in
virtualized Windows 7
Data: Tue, 29 Oct 2013 10:19:08 -0200
De: Felipe Farinon <[email protected]>
<mailto:[email protected]>
Responder a: ZeroMQ development list
<[email protected]>
<mailto:[email protected]>
Para: [email protected]
<mailto:[email protected]>
We can make our own GetTickCount64 built around GetTickCount
and call it when GetTickCount64 is not available in
Kernel32.dll. This code supports Windows 2000 or greater,
whereas calling GetTickCount64 directly from Kernel32.dll
supports only Vista or greater.
static DWORD s_wrap = 0;
static DWORD s_lastTick = 0;
static std::mutex s_wrapMutex;
ULONGLONG MyGetTickCount64()
{
std::unique_lock<std::mutex>_(wrapMutex);
DWORD currentTick = ::GetTickCount();
if (currentTick < s_lastTick)
++s_wrap;
s_lastTick = currentTick;
return (static_cast<ULONGLONG>(s_wrap) << 32) + currentTick;
}
Em 24/10/2013 16:19, Felipe Farinon escreveu:
Unfortunately, GetTickCount64 is only supported on Windows
Vista or greater.
Em 21/10/2013 16:47, Felipe Farinon escreveu:
GetTickCount64 would solve these problems, since it returns
the numbers of millisenconds since the machine has started.
Em 16/10/2013 12:47, Steven McCoy escreveu:
On 16 October 2013 10:25, Laurent Alebarde
<[email protected] <mailto:[email protected]>> wrote:
A simplier approach is to encapsulate the standard
clock of your choice and save in a static member the
value of the last get. Then if the standard clock goes
back in time, you return the saved value + 1.
For clock drift this is fine, one doesn't even have to
bother with the increment for many cases. However there
can be major problems with NTP, daylight savings, and
suspend/hibernation states.
--
Steve-o
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com
_______________________________________________
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
