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

[Archie Cobbs]

On Fri, Sep 2, 2022 at 11:52 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> > So what happens when a virtual thread invokes X? Isn't that going to
> "lock up" the underlying platform thread (or whatever) while X is blocked?
>
> Yes, and that’s what happens for most filesystem operations. We will
> employ io_uring, where available, to use non-blocking filesystem
> operations, but until then (or where io_uring is not available) we
> compensate by adding more OS threads to the scheduler because there’s
> nothing the user can do to avoid it (see JEP 425). User-mode
> threads/coroutine implementations in other languages also suffer from this
> limitation. User-mode code can only work within the confines of the APIs
> provided by the OS.
>

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.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220902/3d356f0f/attachment-0001.htm>