<div dir="ltr"><div dir="ltr">Em sex., 6 de jan. de 2023 às 13:39, Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">I have to agree a bit with Arnaud. I don’t like the idea that I have to “reason about” these issues. Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know “put heartbeat requests on their own native thread” because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn’t lead to the best user experience at times. </div></div></blockquote><div> </div><div>This is the kind of service I provide in practice, not video encoding, but data encryption / decryption. Any single request amounts to getting data, pushing it through some transformation, then forwarding the result. "Sharing" happens because I/O happens. No healthy service instance will exhaust processing capacity at any time for the very simple reason that processing capacity *must* be provisioned to ensure this never happens. If this ever happens, as a consequence of underprovisioned processing capacity, request latency would start to increase unpredictably and we would miss quality targets. The scenario where a processing unit in some data pipeline exhausts processing capacity is unacceptable in general. Time sharing merely allows the system to operate minimally instead of becoming absolutely unresponsive. It cannot solve the actual problem. Processing is not special in this matter. If you read from disk, and you exhaust "I/O slices", the problem would be the same.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>