[External] : Re: jstack, profilers and other tools

[Alex Otenko]

Hi Alan,

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.


Alex

On Mon, 1 Aug 2022, 06:59 Alan Bateman, <Alan.Bateman at oracle.com> wrote:

> On 24/07/2022 14:05, Alex Otenko wrote:
> > :
> >
> > 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.
> >
> I think I've replied to you a few times on topic,  but just to say again
> that we haven't dismissed adding overloads of read that would take a
> supplier or provide other means to lazily get the buffer when there are
> bytes available. This project's position on this has always been that we
> would see how far we would get first. The reason for caution is that
> there are many issues with such APIs (as it's essentially callback at a
> very low level) and in addition it would support through many layers and
> libraries to get any real benefit.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220802/a0df3d90/attachment-0001.htm>