Simon 1 thing you may want to test is 10-20 senders to 1 reciever. Multiple senders have completely diffirent behaviour and can create a lot of contention around locks / interlocked calls . Also checks what happens to CPU when the receiver blocks for 100ms disk accesses every 100ms.
Disruptor as used by Lmax normally uses very few senders / receivers and the main/busy threads do no IO. Ben On Wed, Oct 30, 2013 at 1:03 PM, Simon Ruggier <simo...@gmail.com> wrote: > See my first message, I tested the throughput of the pipes API, it is far > slower. Synchronization between sender and receiver depends on which wait > strategy is used. There is a strategy that blocks indefinitely if no new > items are sent. To see how it works, look at this comment: > > https://github.com/sruggier/rust-disruptor/blob/7cbc2fababa087d0bc116a8a739cbb759354388b/disruptor.rs#L762 > > Multiple senders are also on my roadmap. > > Some things just aren't testable, because the memory ordering guarantees > depend on the hardware you're running on. For it to be truly correct and > portable, the source code has to be simple enough for a reviewer to able to > verify correctness at compile time. The comment I link to above is a good > example, I could never test that code thoroughly enough to be satisfied, a > proof of correctness is the only way. > > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
