Can continuation support finally solve the "How do I stop this thread" problem?
Alan Bateman
Alan.Bateman at oracle.com
Mon Sep 5 08:11:45 UTC 2022
On 02/09/2022 19:28, Archie Cobbs wrote:
> :
>
> OK thanks, now I get it. This limitation inherited from the OS is not
> going to be eliminated or worked around by the new code. So if I
> create 1,000,000 virtual threads and they all call some blocking
> operation then I'm probably in trouble :)
>
> On UNIX at least, AFAIK all blocking operations have a non-blocking
> alternative, so /in theory/ it would be possible to make everything
> unblockable, but of course all internal code - including any JNI
> native code - would have to play along (i.e., be rewritten to use some
> official system call wrapper API). This would be similar to what the
> Pth user-mode threading library does, where they wrap all of the
> blocking system calls with non-blocking versions (link
> <https://www.gnu.org/software/pth/pth-manual.html#standard_posix_replacement_api>)
> and use setcontext/getcontext to context switch.
>
> There are lots of languages (e.g., lua) that have the same issue -
> everything is coroutines, rainbows, and unicorns until some native
> code somewhere calls read(2) or waitpid(2) or whatever. It would be
> cool if someday Java was the one language platform that was able to
> finally fix this, but that's obviously a lot easier said than done.
> I'm not suggesting doing this, just pointing out that it's possible.
>
For virtual threads then ideally all operations that block would allow
the carrier to be released to do other work. The APIs defined by the
Java Platform map to hundred of these operations and the feasibility
mostly depends on OS support. Being able to configure file descriptors
to be non-blocking doesn't help in a many cases, e.g. a file descriptor
to a file opened for buffered I/O is always selectable/ready, which is
why we may have to use async operations where available. If there isn't
any OS support then a virtual thread may temporarily pin its carrier,
which can be compensated for and is usually smooths out as Ron said.
Also it practical terms it shouldn't be a big issue as the file
operations are typically short lived. It is possible of course that
accessing files over the network might block definitely but this should
be rare.
The other topic is cancellation (via Thread.interrupt) where you'd like
blocked Threads to wakeup, maybe throw an exception, and leave objects
in a well-defined state. The lower level challenges overlap with those
of releasing a carrier thread to do other work but the harder part is
the APIs and also needing all code to do the right thing (meaning
checking for interrupt and not swallowing the interrupt status). Many
APIs allow for interruption (Object.wait, Process.waitFor, blocking ops
on an InterruptibleChannel, Selector.select ...) and many do not
(monitor enter, xxxUninterruptibly, ...). We've expanded the set of APIs
that do support interruption in Java 19 and you'll find more on this in
the "Networking" section of JEP 425.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220905/4651c87b/attachment.htm>
More information about the loom-dev
mailing list