<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    On 29/01/2024 22:09, Charles Oliver Nutter wrote:<br>
    <blockquote type="cite" cite="mid:CAE-f1xTY8xyogf6w=KWFYWPqsZAKCfx0M45-0132Ji3fT-beAw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">:

(And yes, I know the implications for vthreads; this is for a user
with legacy code expecting child process pipe streams to be blocking
by default.)

</pre>
    </blockquote>
    <br>
    The source/sink ends of a Pipe are selectable channels and can
    therefore be configured non-blocking. I wonder if the user's code
    chokes with usages like this:<br>
    <br>
    pipe.source().configureBlocking(false);<br>
    pipe.sink().configureBlocking(false);<br>
    <br>
    As regards the underlying blocking mode: It's okay for a
    SelectableChannel to implement blocking semantics when then
    underlying socket/fifo is configured non-blocking. Mostly they are
    the equal, meaning if the SelectableChannel blocking mode is true
    then the underlying socket/fifo's blocking mode is also true. For
    the network channels, the first use of a virtual thread will change
    the channel's socket to be non-blocking. The pipe channels are a 
    bit different in that they eagerly change the underlying fifo to be
    non-blocking. Both are valid approaches as it's transparent to
    anything using the API. The pipe channel could be changed to work
    like the network channels and change it lazily, I think they were
    only done this week for expediency rather than anything else.<br>
    <br>
    -Alan<br>
  </body>
</html>