I'm grateful for the Rust async stuff if only because of the discussions it's prompting across the internet, I'm learning a lot about async models in other programming languages — and also the absolute bonkers stuff some programmers believe about queueing theory 
-
Prikaži ovu nit
-
Here are Peter's Rules 4 Queues (Queue = buffered Go channel, Kafka, ring buffer, whatever) 1. Queues exist only to solve burstiness. If you're not solving burstiness, you should not use a queue.
9 replies 49 proslijeđenih tweetova 123 korisnika označavaju da im se sviđaPrikaži ovu nit -
2. Queues should be fixed size, based on infrastructure capacity. An unbounded queue is like a machine with unlimited memory — a delightful fiction.
7 proslijeđenih tweetova 59 korisnika označava da im se sviđaPrikaži ovu nit -
3. Producers trying to write to a full queue should block, providing backpressure. Consumers reading from a queue that can't process the item in a timely fashion should drop the item and take the next. There is no other sane strategy for dealing with load.
7 replies 6 proslijeđenih tweetova 57 korisnika označava da im se sviđaPrikaži ovu nit -
Odgovor korisniku/ci @peterbourgon
Marius’s corollary: if backpressure is an explicit, not emergent, property of your system, it’s designed wrong.
1 reply 1 proslijeđeni tweet 11 korisnika označava da im se sviđa -
Odgovor korisniku/ci @marius
Interesting. What's the difference between explicit vs. emergent backpressure? (I think I understand, but want to be sure.)
1 reply 0 proslijeđenih tweetova 1 korisnik označava da mu se sviđa -
Odgovor korisniku/ci @peterbourgon
e.g., consider designs that send explicit signals (e.g., in the form of tokens or a callback) vs. “just blocking”. The former have their place, but only rarely, and usually at the bottom most layers of the stack (e.g., TCP!).
0 proslijeđenih tweetova 3 korisnika označavaju da im se sviđa -
Odgovor korisniku/ci @marius
Yes, this is what I understood. Thanks for the confirmation. Queues shouldn't require a control plane.
1 reply 0 proslijeđenih tweetova 1 korisnik označava da mu se sviđa
Another way of putting it: use synchronous APIs, and all will be well.
-
-
Odgovor korisnicima @marius @peterbourgon
Of course, here the overloaded nature of “synchronous” gets confusing: it’s perfectly possible to implement synchronous (in this sense of synchronous) calls on top of an asynchronous event loop, for example.
0 replies 0 proslijeđenih tweetova 1 korisnik označava da mu se sviđaHvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.