Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread Richard Reingruber
On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber wrote: >> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for >> correct (Dekker scheme) synchronization with concurrent execution of >>

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v5]

2024-01-18 Thread Emanuel Peter
On Thu, 18 Jan 2024 17:06:55 GMT, Jatin Bhateja wrote: >> @jatin-bhateja so why do you shift by 5? I thought 4 longs are 32 bit? > > For long/double each permute row is 32 byte in size, so a shift by 5 to > compute row address. Ah right. Maybe we could say `32byte = 4 long = 4 * 64bit`.

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread David Holmes
On Thu, 18 Jan 2024 09:21:24 GMT, Richard Reingruber wrote: >>> It is really safe/correct to move this outside the synchronized block? I >>> know things have changed a bit with loom but we've "always" held a lock >>> when doing the actual interrupt. I'd have to check the VM logic to be sure

Re: Avoiding Side Effects of ForkJoinPool.managedBlock

2024-01-18 Thread David Holmes
On 18/01/2024 7:30 pm, Johannes Spangenberg wrote: Hello, I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Naoto Sato
On Thu, 18 Jan 2024 23:19:44 GMT, Justin Lu wrote: > LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well. Forgot that! Fixed. - PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899410249

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v3]

2024-01-18 Thread Naoto Sato
> Fixing incorrect std/dst transitions for time zones that have rules beyond > 2037. The year 2037 restriction seems to come from the old `zic` command > implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 > which is greater than the year 2087 which is the farthest rule

Re: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static [v2]

2024-01-18 Thread Serguei Spitsyn
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote: >> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be >> static. >> The method disables/enables suspend of the current virtual thread, a no-op >> if the current thread is a platform thread. It is confusing for

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v2]

2024-01-18 Thread Archie Cobbs
On Thu, 18 Jan 2024 23:02:57 GMT, Justin Lu wrote: > Sorry if I'm going over stuff you already know... No apology needed, this stuff is obscure detail madness! > So with this change, although calling `toPattern()` on `new > MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Justin Lu
On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato wrote: >> Fixing incorrect std/dst transitions for time zones that have rules beyond >> 2037. The year 2037 restriction seems to come from the old `zic` command >> implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 >> which

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v2]

2024-01-18 Thread Justin Lu
On Wed, 17 Jan 2024 21:31:22 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to >> pattern string via `toPattern()` and then back via `new MessageFormat()` >> results in a format that is equivalent to the original. >> >> The quoting and escaping

Integrated: 8324053: Use the blessed modifier order for sealed in java.base

2024-01-18 Thread Pavel Rappo
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface > modifier. For context of this change see: > https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. This pull request has now been integrated.

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Joe Wang
On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato wrote: >> Fixing incorrect std/dst transitions for time zones that have rules beyond >> 2037. The year 2037 restriction seems to come from the old `zic` command >> implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 >> which

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Iris Clark
On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato wrote: >> Fixing incorrect std/dst transitions for time zones that have rules beyond >> 2037. The year 2037 restriction seems to come from the old `zic` command >> implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 >> which

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]

2024-01-18 Thread Mandy Chung
On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]

2024-01-18 Thread Mandy Chung
On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]

2024-01-18 Thread Mandy Chung
On Thu, 18 Jan 2024 13:37:12 GMT, Severin Gehwolf wrote: > > If I read the code correctly, the image created with this option will > > enable multi-hops unconditionally? i.e. no timestamp file created and > > disable the check completely. I think the .stamp file should be present in > > any

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]

2024-01-18 Thread Vladimir Yaroslavskiy
On Mon, 11 Dec 2023 03:42:51 GMT, Srinivas Vamsi Parasa wrote: >> Hello Vamsi (@vamsi-parasa), >> >> I made the process simpler: added all variants to be compared into >> ArraysSort class >> (set the same package org.openjdk.bench.java.util). It will run all sorts >> incl. sort from jdk >>

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

2024-01-18 Thread Archie Cobbs
On Thu, 18 Jan 2024 20:08:27 GMT, Justin Lu wrote: >> Hi @justin-curtis-lu, >> >> Thanks a lot for taking a look, I am glad for any other set of eyes on this >> tricky stuff! >> >>> As it stands, it would be inconsistent to have the closing bracket quoted >>> and the opening bracket not

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Naoto Sato
> Fixing incorrect std/dst transitions for time zones that have rules beyond > 2037. The year 2037 restriction seems to come from the old `zic` command > implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 > which is greater than the year 2087 which is the farthest rule

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect [v2]

2024-01-18 Thread Naoto Sato
On Thu, 18 Jan 2024 20:48:03 GMT, Iris Clark wrote: > Hopefully "2100" is unique enough that you'll be able to easily > search/replace the next time you need to extend. Thank you, Iris. Added a comment to clarify the need for possible expansion. - PR Comment:

Re: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect

2024-01-18 Thread Iris Clark
On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato wrote: > Fixing incorrect std/dst transitions for time zones that have rules beyond > 2037. The year 2037 restriction seems to come from the old `zic` command > implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 > which is

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v2]

2024-01-18 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has updated the pull request

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes

2024-01-18 Thread Jim Laskey
On Thu, 18 Jan 2024 19:25:28 GMT, Raffaello Giulietti wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

2024-01-18 Thread Justin Lu
On Wed, 17 Jan 2024 21:31:49 GMT, Archie Cobbs wrote: >> Hi Archie, thanks for the proposed fix. I am still taking a look, but I >> wanted to demonstrate a current issue, >> >> (Jshell with your patch) >> >> >> var pattIn = "Test: {0,number,foo'{'#.00}"; >> MessageFormat mFmt = new

RFR: 8324065: Daylight saving information for `Africa/Casablanca` are incorrect

2024-01-18 Thread Naoto Sato
Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes

2024-01-18 Thread Raffaello Giulietti
On Thu, 18 Jan 2024 18:50:56 GMT, Jim Laskey wrote: > Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage,

RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes

2024-01-18 Thread Jim Laskey
Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage, - Commit messages: - Unicode escape sequences

Integrated: 8324161: validate-source fails after JDK-8275338

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 17:39:47 GMT, Daniel D. Daugherty wrote: > A trivial fix to the copyright line in > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. This pull request has now been integrated. Changeset: 5c874c19 Author:Daniel D. Daugherty URL:

Re: Integrated: 8324161: validate-source fails after JDK-8275338

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 17:41:04 GMT, Joe Darcy wrote: >> A trivial fix to the copyright line in >> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the lightning fast review! - PR Comment:

Re: Integrated: 8324161: validate-source fails after JDK-8275338

2024-01-18 Thread Joe Darcy
On Thu, 18 Jan 2024 17:39:47 GMT, Daniel D. Daugherty wrote: > A trivial fix to the copyright line in > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. Marked as reviewed by darcy (Reviewer). - PR Review:

Integrated: 8324161: validate-source fails after JDK-8275338

2024-01-18 Thread Daniel D . Daugherty
A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. - Commit messages: - 8324161: validate-source fails after JDK-8275338 Changes: https://git.openjdk.org/jdk/pull/17490/files Webrev:

Re: RFR: 8159927: Add a test to verify JMOD files created in the images do not have debug symbols

2024-01-18 Thread Jim Laskey
On Wed, 17 Jan 2024 20:51:23 GMT, Mandy Chung wrote: > The build excludes the native debug symbols in JMOD files created for JDK > modules (see make/CreateJmods.gmk). This PR adds a test to verify that > native debug symbols are excluded as expected. LGTM - Marked as reviewed

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v5]

2024-01-18 Thread Jatin Bhateja
On Tue, 16 Jan 2024 07:08:57 GMT, Emanuel Peter wrote: >> Each long/double permute lane holds 64 bit value. > > @jatin-bhateja so why do you shift by 5? I thought 4 longs are 32 bit? For long/double each permute row is 32 byte in size, so a shift by 5 to compute row address. - PR

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v6]

2024-01-18 Thread Jatin Bhateja
> Hi, > > Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only > targets. > Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 > instruction set. > These are very frequently used APIs in columnar database filter operation. > > Implementation uses a

Integrated: 8275338: Add JFR events for notable serialization situations

2024-01-18 Thread Raffaello Giulietti
On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti wrote: > Adds serialization misdeclaration events to JFR. This pull request has now been integrated. Changeset: bfd2afe5 Author:Raffaello Giulietti URL:

Re: Gatherer: spliterator characteristics are not propagated

2024-01-18 Thread Viktor Klang
And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted. That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some

Re: Avoiding Side Effects of ForkJoinPool.managedBlock

2024-01-18 Thread Johannes Spangenberg
> On the REE, this is also controlled by JUnit when it creates the FJP. > The saturate parameter is the predicate that is determines if REE is > thrown or the pool continues without an additional thread. Thanks, I missed that unfortunately. My version of JUnit uses null for the saturate

Re: [jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 15:36:07 GMT, Albert Mingkun Yang wrote: >> A trivial fix to disable core file generation in >> java/foreign/critical/TestCriticalUpcall.java. > > Marked as reviewed by ayang (Reviewer). @albertnetymk - Thanks for the fast review! - PR Comment:

[jdk22] Integrated: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 15:20:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. This pull request has now been integrated. Changeset: b1788944 Author:Daniel D. Daugherty URL:

Re: [jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-18 Thread Albert Mingkun Yang
On Thu, 18 Jan 2024 15:20:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. Marked as reviewed by ayang (Reviewer). - PR Review:

Re: Gatherer API : wildcards complaint

2024-01-18 Thread forax
> From: "Viktor Klang" > To: "Remi Forax" > Cc: "core-libs-dev" > Sent: Wednesday, January 17, 2024 9:00:32 PM > Subject: Re: Gatherer API : wildcards complaint > Ah, now I see what you mean! Thank you \uD83D\uDC4D > The reason for the signature of `Gatherer.of` was to mirror as much as >

[jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-18 Thread Daniel D . Daugherty
A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java. - Commit messages: - Backport a22ae909bc53344afd9bb6b1f08ff06858c10820 Changes: https://git.openjdk.org/jdk22/pull/90/files Webrev: https://webrevs.openjdk.org/?repo=jdk22=90=00

Re: Gatherer: spliterator characteristics are not propagated

2024-01-18 Thread forax
> From: "Viktor Klang" > To: "Remi Forax" > Cc: "core-libs-dev" , "Paul Sandoz" > > Sent: Thursday, January 18, 2024 3:36:07 PM > Subject: Re: Gatherer: spliterator characteristics are not propagated > I suspect that it is a rather slippery slope, once KEEP-flags are added, then > others will

Re: Gatherer: spliterator characteristics are not propagated

2024-01-18 Thread Viktor Klang
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc. And that's even before one looks at the composition-part of it, what

Withdrawn: 8315585: Optimization for decimal to string

2024-01-18 Thread duke
On Mon, 2 Oct 2023 05:40:03 GMT, Shaojin Wen wrote: > I submitted PR #1 before, and there were too many changes. I split it > into multiple PRs with small changes. This one is one of them. > > this PR removed the duplicate code for getChars in > BigDecimal#StringBuilderHelper, i also make

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]

2024-01-18 Thread Severin Gehwolf
On Tue, 19 Dec 2023 19:14:42 GMT, Mandy Chung wrote: >> Severin Gehwolf has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Disallow packaged modules and run-time image link >> - Only check for existing path when not a scratch task >>

Integrated: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 00:58:49 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. This pull request has now been integrated. Changeset: a22ae909 Author:Daniel D. Daugherty URL:

Re: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file [v2]

2024-01-18 Thread Daniel D . Daugherty
On Thu, 18 Jan 2024 07:47:54 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update copyright year. > > Good and trivial. > > Copyright year needs updating. > > Thanks @dholmes-ora -

Re: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file [v2]

2024-01-18 Thread Daniel D . Daugherty
> A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. - Changes: - all:

Re: Avoiding Side Effects of ForkJoinPool.managedBlock

2024-01-18 Thread Alan Bateman
On 18/01/2024 09:30, Johannes Spangenberg wrote: Hello, I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change

Re: RFR: 8324053: Use the blessed modifier order for sealed in java.base

2024-01-18 Thread Pavel Rappo
On Thu, 18 Jan 2024 09:29:11 GMT, Magnus Ihse Bursie wrote: > Thanks! When this has been integrated, I can take a shot at the missorted > `default`s. Thanks, I could've done that myself, but decided not to. You see, `default` should ideally be a [sole] modifier on a method: all other

Re: RFR: 8324053: Use the blessed modifier order for sealed in java.base

2024-01-18 Thread Daniel Fuchs
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface > modifier. For context of this change see: > https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. LGTM - Marked as reviewed by dfuchs

Avoiding Side Effects of ForkJoinPool.managedBlock

2024-01-18 Thread Johannes Spangenberg
Hello, I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change the behavior of the code. These changes in behavior

Re: RFR: 8324053: Use the blessed modifier order for sealed in java.base

2024-01-18 Thread Magnus Ihse Bursie
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface > modifier. For context of this change see: > https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. Thanks! When this has been integrated, I can take a

Re: Gatherer: spliterator characteristics are not propagated

2024-01-18 Thread forax
> From: "Viktor Klang" > To: "Remi Forax" , "core-libs-dev" > > Sent: Wednesday, January 17, 2024 8:48:07 PM > Subject: Re: Gatherer: spliterator characteristics are not propagated > Hi Rémi, > You can find some of my benches here: [ >

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread Richard Reingruber
On Thu, 18 Jan 2024 08:32:02 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Thread.java line 1709: >> >>> 1707: // Setting the interrupt status must be done before reading >>> nioBlocker. >>> 1708: interrupted = true; >>> 1709: interrupt0(); //

Re: Seing a Collector as a Gatherer

2024-01-18 Thread Viktor Klang
Yes, having the conversion in Gatherers would seem like the most sensible option. Then the question becomes whether gather is the most sensible name for it―I'm thinking of readability under the use of static imports etc. gatherUsing(), viaCollector(), adapt(), etc. Cheers, √ Viktor Klang

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread Alan Bateman
On Thu, 18 Jan 2024 08:02:27 GMT, David Holmes wrote: > It is really safe/correct to move this outside the synchronized block? I know > things have changed a bit with loom but we've "always" held a lock when doing > the actual interrupt. I'd have to check the VM logic to be sure it can be >

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread Richard Reingruber
On Wed, 17 Jan 2024 21:18:27 GMT, Christoph Langer wrote: >> Richard Reingruber has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review Alan > > test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java line 2: > >> 1: /* >> 2: *

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread David Holmes
On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber wrote: >> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for >> correct (Dekker scheme) synchronization with concurrent execution of >>