Single Thread Continuation

[Andrii Lomakin]

Hi Robert

The primary use case should not be identified only by the immediate use
case of people working in the same area.
I have talked with lead developers of several companies that produce
mainstream and quite popular products (which I can not name
for confidentiality reasons, though I completely understand that my claim
does not look very persuasive in such form), who confirmed that they do
need the support of custom schedulers for efficient integration of io_uring
based solutions.

As you can see in this thread there are also other reasons aside from usage
of io_uring why custom schedulers must be implemented.
Which together form quite a big amount of use cases to pay attention to.


On Mon, Jul 3, 2023 at 1:59 AM Robert Engels <rengels at ix.netcom.com> wrote:

> When you have virtual threads there is no need for generators - it is
> simply queues. The typical generator is simply implemented as a task that
> puts values on a queue with blocking semantics. The rest is syntactic
> sugar.
>
> On Jul 2, 2023, at 5:53 PM, Attila Kelemen <attila.kelemen85 at gmail.com>
> wrote:
>
> 
> Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. júl. 2.,
> V, 23:52):
>
>> I would fully avoid all of these isolated use case. Virtual threads
>> solves the primary need for Java - thread per connection.
>>
>> All of these other uses can be done in other languages - don’t pollute
>> Java with less useful idioms that solves peoples need to not have to learn
>> CS.
>>
>>
> I can't see how adding the possibility for generators would be "less
> useful idioms that solves peoples need to not have to learn CS". It has
> nothing to do with that, and it would be terribly useful, because there are
> a lot of cases, where you already have APIs that can "for-each" over
> something, and these generators would provide considerable value. And even
> when you could implement an `Iterator`, implementing it certainly doesn't
> fall into a big intelectual challenge, rather it is just cumbersome for
> basically no gain. In fact, if there is any reason to avoid adding features
> is because people might find it complicated to understand, and not as you
> imply that it would make it easy for less qualified people (which I don't
> even understand why would be an issue).
>
> Attila
>
>

-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/ac15566d/attachment.htm>