<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 04/10/2024 08:31, Danny Thomas wrote:<br>
<blockquote type="cite" cite="mid:CAABjz12ictdBHxTOgMusZE0YmqhX1wJXC6z5j085QvNgikLP-g@mail.gmail.com">
<div dir="auto">I’d wondered about the external submit changes;
I’ll take your word for it :)</div>
<div dir="auto"><br>
</div>
<div dir="auto">Does seem that if you do expose an API, you’d want
to differentiate things such as unpark/yield from other
submissions. <br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I guess there’s also pathological cases where a VT
is primarily driving creation of virtual threads in an
application. <span style="font-family:-apple-system,helveticaneue;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">I’ve
tried a few heuristics for deciding when to externally submit
instead of locally submitting to a FJP, and I found it
difficult to avoid prematurely and ineffectively moving work;
but I am working with purposefully contrived benchmarks right
now, rather than something that looks like a real application.</span></div>
</blockquote>
<br>
Virtual threads unparking other virtual threads will be common,
anything CSP like, or using locks that are contended, means the
custom scheduler's execute method will be called in the context of a
virtual thread that is unparking another virtual thread.<br>
<br>
Very application dependent as to whether you'll see virtual threads
starting other virtual threads. A web server where the listener is a
platform thread may start a virtual thread for each connection, not
too interesting. However, anything using structured concurrency
where there the tree goes beyond a single level will lead to virtual
threads forking new virtual threads.<br>
<br>
I don't think we are close to exposing any API at this point. There
is list of possible things that could be interesting but it's a big
step to commit to an interface.<br>
<br>
-Alan<br>
</body>
</html>