On Jun 11, 2010, at 1:05 PM, Martin Sustrik wrote: >> One problem that results is that the receiving socket would be in the >> "ready" state after receiving the response, but the rest of the >> network would not reflect that. If another request were sent with the >> same identity it could trounce state elsewhere. > >> Otherwise, I think you would have to build the device into zmq where >> it could directly mangle the pipes and sockets :-) > > Yes. I think so. But it's not that difficult as it may seem. > > What's really difficult is that there's no cross-platform > thread-friendly highly-efficient timer mechanism.
Does it help timer performance if the timeout resolution is coarse like milliseconds? I can imagine in some very high frequency scenario where someone might want a timer that expires in as little as 1 millisecond, but I can't think of reasonable cases for usec or nanosec timer resolution. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
