nicholas at nichol.as
Wed Jun 9 19:22:18 CEST 2010
On Jun 9, 2010, at 7:00 PM, gonzalo diethelm wrote:
>>> I agree wholeheartedly. I think the timing functions should stay and
>>> supported portably across platforms.
>>> There is/was also a zmq_sleep() function in there. Will it be kept?
>>> Should it?
>> I don't think that is needed.
> I agree.
>>> At some point I also proposed adding a zmq_uuid() generation
>>> but it was decided it was beyond 0MQ's scope. Perhaps we could come
>>> with clear cut criteria for what kinds of functions belong in 0MQ.
>> I do agree with Martin that 0MW should not become a portability
>> library. In short, we need some other reason to include something in
>> the API. For the case of timing, that additional factor is
>> timing/benchmark uniformity and consistency. I don't see what that
>> additional factor is for zmq_uuid, so I would tend to say no.
> Just to clarify, I was not proposing (again) to add this function;
> rather, I was providing it as an example of a rejected function
> according to criteria that perhaps should be clarified. I agree with you
> that zmq_uuid() should not go into 0MQ.
I think those criteria are somewhat summed up in the mails by Brian.
* Performance is an (the most?) important aspect of 0MQ
* Comparing (and verifying) different implementations is difficult without a reliable and consistent clock implementation
* Even when a separate library exists this would be an extra dependency for (all) the bindings developers
* It is not really an option to benchmark different implementations against each other with an external stopwatch (such as Unix time) as this would, for example, also include interpreter start up time for interpreted languages.
So, i would also like to see stopwatch being part of 0MQ again and it would be great if all binding developers would provide a benchmark suite that relies on this implementation.
More information about the zeromq-dev