<div dir="auto">Hi Alan,<div dir="auto"><br></div><div dir="auto">I remember that. I agree with the position you sound here. In this context I was only pointing out that whereas mathematically "direct" style and continuation passing are equally powerful, in practice there are barriers caused by APIs.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Alex</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Aug 2022, 06:59 Alan Bateman, <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 24/07/2022 14:05, Alex Otenko wrote:<br>
> :<br>
><br>
> Also, I am not clear why you dismissed the allocation problem by just <br>
> saying IO buffering is the same. The allocation problem is that user <br>
> code allocates before read(byte[]) is called. This is the same in both <br>
> sync and async code. The difference is that in async code the lifespan <br>
> of the allocation is shorter - we read only read-ready channels, and <br>
> those that aren't ready return quickly. In sync code the buffer <br>
> remains allocated for a long time - even seconds, if that's what the <br>
> connection reuse pattern is on the client side.<br>
><br>
I think I've replied to you a few times on topic,  but just to say again <br>
that we haven't dismissed adding overloads of read that would take a <br>
supplier or provide other means to lazily get the buffer when there are <br>
bytes available. This project's position on this has always been that we <br>
would see how far we would get first. The reason for caution is that <br>
there are many issues with such APIs (as it's essentially callback at a <br>
very low level) and in addition it would support through many layers and <br>
libraries to get any real benefit.<br>
<br>
-Alan<br>
</blockquote></div>