It's not a problem to offer non-blocking functions on both the send and receive sides, in addition to the blocking ones. It's up to callers to choose what's right for their application, but at the same time, they shouldn't have to reinvent the wheel. The reason it's not in there yet is that riskier items were and are my first priority.
On Wed, Oct 30, 2013 at 1:44 PM, Matthieu Monrocq < [email protected]> wrote: > If I may suggest, rather than blocking the sender in case the channel is > full, I suggest simply returning an error (or raising a condition) > immediately. > > This is both extremely simple (for the channel implementer) and heavily > customizable (for the user). > > It seems certainly much easier than provide an extremely wide array of > different channels as part of the core Rust distribution... and actually > makes it possible to build libraries for common cases (such as local > queuing). > > -- Matthieu. > > > On Wed, Oct 30, 2013 at 6:37 AM, Ben Kloosterman <[email protected]>wrote: > >> 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 <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
