On 4/26/10, Martin Sustrik <[email protected]> wrote: > Pieter Hintjens wrote: >> On Mon, Apr 26, 2010 at 10:09 PM, Martin Sustrik <[email protected]> >> wrote: >> >>>> Wouldn't happen like that, rather allocate fixed shmem buffers that >>>> are reused for smaller messages. And use signals to indicate new >>>> data... no? >>> Definitely doable. But that's what OS-provided IPC mechanism does under >>> covers. Once you go that way you find yourself competing with kernel >>> implementation of the same thing. >> >> Are signals as fast as, or slower than inproc? > > They are slower. > >>> Not that it's not doable. There've been a discussion on the list where >>> someone proposed busy-looping when waiting for incoming data, thus >>> by-passing the kernel. Still, my feeling is that such measures are a bit >>> drastic even for a HPC solution like 0MQ. >> >> Busy-looping makes sense (except for energy consumption) when there's >> one core per task, and that's kind of where things are heading... > > If anyone is willing to take a try on that, why not. But be warned: It's > complex and the reward may be not worth of the effort invested. >
I heard people are doing this in the trading world as latency is very sensitive. I think 0mq should at least have this optional implementation available; people can choose to use it at their own risk. Is there any open source projects that have such "crazy" implementation? >> Might be worth collecting this into a design whitepaper. > > Sure. I've gave up writing design whitepapers after version 0.6 :) > > Martin > _______________________________________________ > 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
