<div dir="ltr"><div dir="ltr">Em dom., 24 de jul. de 2022 às 10:08, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com">oleksandr.otenko@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><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="auto">Also, I am not clear why you dismissed the allocation problem by just saying IO buffering is the same. The allocation problem is that user code allocates before read(byte[]) is called. This is the same in both sync and async code. The difference is that in async code the lifespan of the allocation is shorter - we read only read-ready channels, and those that aren't ready return quickly. In sync code the buffer remains allocated for a long time - even seconds, if that's what the connection reuse pattern is on the client side.</div></div></blockquote></div><div><br></div><div>I am not what this allocation problem is supposed to be.</div><div>If you have provisioned the memory required to support your workload,</div><div>it doesn't matter for how long some buffer remains "inside" a call.</div><div>If you have not provisioned the memory required to support your workload,</div><div>then you have an architectural problem no matter how little time some buffer remains "inside" a call;</div><div>you will crash when concurrent reads peak.</div><div>Am I missing something?</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>