On 25/12/2013 01:45, Daniel Micay wrote:
Unbounded channels don't provide a
way to write robust systems without layering on application-level
message passing and book-keeping.
Can I point out that flow control isn't necessarily just back to the
immediate producer?
It is relatively unusual to have a system that spontaneously explodes
through
internal messaging. Normally event chains start from an external event and
the resulting peak load on internal messaging can be estimated (and
controlled).
So we have two types of queues - one handling external events and one
handling
internal messaging.
It is also useful to consider this as three types:
- external queues for unsolicited requests (ie externally initiated
events)
- external queues for response events to requests we made
- internal queues
In most systems, what you really want is:
- keep processing external responses (to avoid deadlocks)
- keep processing internal events
- back pressure to slow or stop unsolicited requests
Are you sure this isn't most directly handled by having a means to inspect
the total resource pressure and attaching events to thresholds, so that
input channels can be controlled? Not all input channels are created
equal; the admin and diagnostics interface (whether an embedded web gui
or something else needs (ideally) to keep going when interactive and batch
feeds are stalled.
It concerns me that providing back pressure to the immediate chain only
can lead to a lot of messy propagation code. And its code that's not so
easy
to test or reason about.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
