Can continuation support finally solve the "How do I stop this thread" problem?

[Alan Bateman]

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>