<!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>