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. > 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
