<div dir="ltr"><div dir="ltr">On Thu, Sep 1, 2022 at 11:42 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> So my question is simply what's the implementation distance between X <br>
> and Y? Where X = [We are now after implementing virtual threads], and Y <br>
> = [The ability to always unblock a blocked thread].<br>
> <br>
> For the sake of clarity let's assume whoever wants to do this is able to <br>
> rewrite bytecode (e.g., to add checks for a "stop" flag on backward <br>
> branches) to avoid infinite loops, etc., so the only real barrier is the <br>
> thread being stuck in a blocking method call.<br>
<br>
To which the only general solution is "only block using mechanisms you <br>
control and which are interruptible". There is no general solution to a <br>
blocking OS call unless the OS provides a mechanism to do so.</blockquote><div><br></div>OK, it sounds like you're saying that there exists some system call X from which we can't unblock a thread.<br></div><div class="gmail_quote"><div><br></div>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?<br><div><br></div><div>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>