Hi Java Experts,
I sent this email incorrectly to loom-dev@ and was told on Reddit that
core-libs-dev is the right list.
The question is about the behavior of mapConcurrent() when the thread is
interrupted.
Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
then stop at wha
them.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Jige Yu
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang
> *Cc:* core-libs-dev@openjdk.org
> *Subject
focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Viktor Klang
> *Sent:* Thursday, 6 February 2025 11:51
>
t; This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Softw
for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> √
>
>
> *Viktor Kl
Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Jige Yu
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Vik
pagation of interruption in CountedCompleters.
> Adding support for such in (at least) GathererOp needs further study before
> contemplating making any changes to mapConcurrent()'s interruption policy.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java
t interrupt status is maintained, which is possible in this case.
>
> I have given it some more thought in the meantime, but I haven't arrived
> in something more satisfactory than that, yet.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platfo
rentThread().interrupt();
throw new UncheckedInterruptedException();
}
What are the concerns against such practice?
On Mon, May 26, 2025 at 8:31 AM Jige Yu wrote:
> Yeah, I think I missed the task cancellation and the joining part.
>
> When the mapConcurrent() thread is interrupted
heers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Jige Yu
> *Sent:* Wednesday, 28 May 2025 00:35
> *To:* Viktor Klang
> *Cc:* core-libs-dev@openjdk.org
> *Subject:* Re: [External] :
Sorry. Forgot to copy to the mailing list.
On Mon, Jun 2, 2025 at 7:27 AM Jige Yu wrote:
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
>
ich adds to the complexity
> of the implementation. Implementing an unordered version would likely look
> different.
> I'd definitely encourage taking the opportunity to attempt to implement it.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform
cases.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-libs-dev on behalf of Jige
> Yu
> *Sent:* Friday, 30 May 2025 00:44
> *To:* David Holmes
> *Cc:* core-libs-dev@openjdk.
race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
>
It seems like for most people, input order isn't that important for
concurrent work, and concurrent results being in non-deterministic order is
often expected.
If mapConcurrent() just respect output encounter order:
It'll be able to achieve *higher throughput* if an early task is slow, For
exampl
gt;
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Jige Yu
> *Sent:* Monday, 2 June 2025 18:54
> *To:* Viktor Klang
> *Cc:* core-libs-dev@openjdk.org
> *Subject:* Re: [External] : Re: Should mapConcurre
gracefully by letting tasks run
truly concurrently without an implicit ordering dependency.
This reinforces my belief that an alternative gatherer, or a default
behavior for mapConcurrent() that prioritizes concurrency (as the name
mapConcurrent might suggest to many, akin to forEach), could be very
ptions work fine too.
I can't see harm being done for either case, compared to letting it keep
running through all elements (what if the stream is infinite or very very
long?)
On Wed, May 28, 2025 at 10:19 PM David Holmes
wrote:
> On 29/05/2025 3:45 am, Jige Yu wrote:
> > 17.2.
a/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* Jige Yu
> *Sent:* Wednesday,
s interrupted.
On Thu, Jul 3, 2025 at 10:29 AM David Alayachew
wrote:
> These questions necessitate runnable examples. Do you have any
>
> On Thu, Jul 3, 2025, 10:37 AM Jige Yu wrote:
>
>> Hi JDK Core Devs,
>>
>> I'm writing to you today with a
Hi JDK Core Devs,
I'm writing to you today with a question about the behavior of
mapConcurrent() and its interaction with unchecked exceptions. I've been
experimenting with the API and observed that mapConcurrent() blocks and
joins all virtual threads upon an unchecked exception before propagating
e. Being a collector, it needs to first consume the
input, similar to how most Collectors operate. So it might be a less
intrusive path to ensure proper resource handling without altering usage
patterns.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform G
t;
> Would you mind clariying *exactly* what you mean here—*what* happens-before
> completion/exception?
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> --
> *From:* Jige Yu
> *Sent:*
ats around happens-before
enforcement and thread cancellation.
Just my 2c,
Cheers
On Fri, Jul 4, 2025 at 8:55 AM Jige Yu wrote:
> Yes.
>
> I got two tests that show the behavior difference between downstream
> exception and upstream exception:
>
>
> @Test public void map
he meantime, I want to reiterate that it is possible to build what
> you're asking for, outside of the JDK. To gather experience, feedback, and
> ultimately decide if the feature is worthwhile.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Gr
25 matches
Mail list logo
