[External] : Re: Structured Concurrency API ?

Alex Otenko oleksandr.otenko at gmail.com
Mon Apr 11 20:16:17 UTC 2022


That doesn't answer my question.

The point I was making is that you can't be spinning up one Virtual thread
per item produced, as the number of items produced can be large, and you
can't be spinning up one Virtual thread per item consumed, as the number of
consumed items can be small.

(My question was about your remark about spinning up a thread per item
consumed - is that what parallel() does? That'd be surprising)

Alex

On Mon, 11 Apr 2022, 20:45 Ron Pressler, <ron.pressler at oracle.com> wrote:

> Any operation requires a certain amount of resources, and if it’s more
> than you have, then obviously you need to consider the implications. But
> CPU is one kind of limited resource and threads are a whole other kind.
> Here we’re talking about cases where threads are the more relevant
> resource, as opposed to CPU, which is what Stream.parallel() currently
> contends with.
>
> — Ron
>
> On 11 Apr 2022, at 19:19, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>
> Usually I use that argument to start thinking along the lines of "what if
> it is bigger than you think", rather than actually infinite.
>
> (For any N as big as you choose to handle, N+1 exists, and you are not
> prepared to handle it)
>
> Ok, the stream is infinite, you filter on predicate, then limit to produce
> 1 - does this mean it will use just 1 CPU to produce the values? If that is
> so, I am surprised.
>
> Alex
>
> On Mon, 11 Apr 2022, 18:18 Ron Pressler, <ron.pressler at oracle.com> wrote:
>
>>
>> > On 11 Apr 2022, at 15:57, Alex Otenko <oleksandr.otenko at gmail.com>
>> wrote:
>> >
>> > ...for finite Streams
>> >
>> >
>> > Alex
>>
>> Obviously, as many threads as _consumed_ items, which are always finite
>> regardless of the finiteness of the source.
>
>
>


More information about the loom-dev mailing list