[zeromq-dev] montonic clock II

julien tayon julien at tayon.net
Wed Oct 2 16:20:42 CEST 2013

Hello Pieter & all

* Theo de raadt on going longlong

* monotonic clock & issues in  python :

* An implementation of monotonic timer same as yours + comment pointing out

Joke : I won't write the patch since I did not coded seriously in cpp since
1998 :)

More seriously I can't write the test to prove there is a bug.

Rough guess is : set clock in (future|past)
Begin something involving time (like a scheduler)
During the "sleep"/Time Interval ntp adjust clock
Fail test if we lost events

I don't know enough of the internals of zmq to write the test, and code not
tested for me is as good as nothing.

First bis: casting is wrong

on linux __time_t SLONGWORD does not cast to int64 but a machine word : a
signed 64 on amd64 a signed int on ia32. (I checked that)

Secondly: linux is not POSIX
even though BSD happily maps monotonic raw clock to 4 Since I read a slide
Theo de radt wrote @euroBSDCon we can expect a change in __time_t
His rationale his since embedded is a slow moving plaform we can expect 32
bits architecture in production in 2038 to give time to time  he proposes
that tv_sec not be casted as signed long but unisgned long (32 bits instead
of 31 bits being used for seconds it buys us 6X years).

So expect openBSD to soon have a discretancy with linux.

Thirdly BSD and linux are not POSIX
I have not read POSIX since a long time and I poorly admit I don't know how
to make portable code.
There may be a POSIX compliant nice way to do it.
And I fear the hell of pragma and inhomogeneities in platform
dependant/libc/kernel for the sizeof long values. (like having sizeof(long)
varying) because I am not familiar anymore with all the ANSI C norms nor
automake, autoconfigure settings.

I am not a decent C coder anymore, for I fear the classical everyday
problems C/C++ coders solve with an ignored maestria :)


BTW I stumble on your code because I also needed a monotonic raw clock and
expected you to export it in your libary. I was just checking you did not
had my problem. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131002/d83f2966/attachment.htm>

More information about the zeromq-dev mailing list