Hi, But don’t you have to use interrupts - that is the only way to force a return from many if not all system calls? - except for socket calls where I think you need to close the socket to interrupt a blocking read.
> On Dec 1, 2025, at 4:48 PM, Attila Kelemen <[email protected]> wrote: > > In my opinion, the core of the issue is not the behavior of close (if it did > shutdownNow, then there are other nasty things which could happen, and would > be equally surprising, but in other circumstances). The root of the problem > is that thread interruption is a poor way to manage cancellation (they suffer > from the same issue as global variables do). This poor cancellation mechanism > was the main reason I created my own executor framework a long time ago. I > wish Java never tried to use thread interrupts for cancellation. > > Stig Rohde Døssing <[email protected] <mailto:[email protected]>> > ezt írta (időpont: 2025. dec. 1., H, 21:17): >> Hi, >> >> I stumbled on a minor landmine with newVirtualThreadPerTaskExecutor, and >> figured I'd share in case something can be done to communicate this behavior >> a little better, because it caught me by surprise. >> >> JEP 444 suggests code like the following >> >> try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { >> var future1 = executor.submit(() -> fetchURL(url1)); >> var future2 = executor.submit(() -> fetchURL(url2)); >> response.send(future1.get() + future2.get()); >> } catch (ExecutionException | InterruptedException e) { >> response.fail(e); >> } >> >> This led me to believe that I could write code like that, and get something >> that reacts to interrupts promptly. But unfortunately, the close method on >> this executor does not interrupt the two submitted fetches. Instead, if the >> main thread in this code is interrupted, the thread will block until the two >> fetches complete on their own time, and then it will fail the request, which >> seems a little silly. >> >> Due to how try-with-resources works, the executor is closed before the catch >> block is hit, so in order to "stop early" when interrupted, you'd need to >> add a nested try-catch inside the try-with-resources to either interrupt the >> two futures or call shutdownNow on the executor when the main thread is >> interrupted. >> >> I know that the structured concurrency API will be a better fit for this >> kind of thing, but given that virtual threads are likely to spend a lot of >> their time blocking waiting for something to occur, it seems a little >> unfortunate that the ThreadPerTaskExecutor for virtual threads doesn't do >> shutdownNow on close when used in the most straightforward way.
