Single Thread Continuation

Alex Otenko oleksandr.otenko at gmail.com
Mon Jul 3 09:33:29 UTC 2023


It should be two queues, really. Java's blocking queues do not implement
the required semantics.

On Mon, 3 Jul 2023, 00:59 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/09356b4b/attachment-0001.htm>


More information about the loom-dev mailing list