<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 02/09/2022 19:28, Archie Cobbs wrote:<br>
<blockquote type="cite" cite="mid:CANSoFxtyX1iqWwVYDgt+0sW+rRE0LOHJdbqG_k7DB12WmZ1J2Q@mail.gmail.com">
<div dir="ltr">:
<div class="gmail_quote">
<div><br>
</div>
<div>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 :)<br>
</div>
<div><br>
</div>
<div>On UNIX at least, AFAIK all blocking operations have a
non-blocking alternative, so <i>in theory</i> 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 (<a href="https://www.gnu.org/software/pth/pth-manual.html#standard_posix_replacement_api" target="_blank" moz-do-not-send="true">link</a>) and use
setcontext/getcontext to context switch.<br>
</div>
<div><br>
</div>
<div>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.</div>
<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
</body>
</html>