On Tue, Feb 26, 2019 at 8:38 AM Jiri Daněk <[email protected]> wrote:
> Hi folks, > > I am trying to get myself oriented in tracking time in qpid proton (and > qpid dispatch). There is a variety of c types used for this purpose: > > int64_t, uint64_t, pn_timestamp_t (int64_t), pn_millis_t (unit32_t) > qd_timestamp_t (int64_t), qd_duration_t (int64_t) > > pn_timestamp_t is for AMQP timestamps, so the use is clear to me and the > underlying type cannot be anything else than int64_t because the spec says > so. > > Regarding the remaining types, it is not clear to me > 1) when to use plain c type and when to use one of the typedefs, especially > pn_millis_t and qd_timestamp_t > The typedefs exist to clarify intent - whether you are specifying a time interval (pn_millis_t, qd_duration_t) or a point in time (pn_timestamp_t, qd_timestamp_t). When you're doing calculations it doesn't much matter if you use plain int types as long as they're big enough for the result, but for parameters and return values it's helpful to use a descriptive typedef. > 2) what is the rationale in making choice between 32bit and 64bit integer, > Historical - in new code I would use 64bit everywhere - which is what dispatch does - but proton is stuck with 32 bits pn_millis_t for historical reasons. > 3) when to use signed and when unsigned type. > In new code I would use signed 64 bit everywhere, it makes arithmetic much easier. We're stuck with unsigned pn_millis_t for historical reasons. > Specifically, lets say for storing value of monotonic clock counting in > milliseconds. It is clear I want 64bit type, because 32bits overflow in 48 > days of uptime. Now about sign, proton currently variously uses both > int64_t and uint64_t, maybe because libuv has uint64_t as return value for > uv_now(), etc. Unsigned types can be generally tricky in some ways (which > should be justification why Java does not have them) and it is reasonable > to have negative differences between timestamps. Which argues for signed > type for me. Then again, doing the conversions, like storing result of > uv_now() to int64_t would feel "dirty" to me... And then I find > pn_proactor_now(), which currently returns pn_millis_t, which is 32bit > type. > I'd use int64 in new code, and wash your hands after conversions. If you're counting in milliseconds the bugs won't be reported for several thousand years, so not top priority for this sprint. > -- > Mit freundlichen Grüßen / Kind regards > Jiri Daněk >
