<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 28/05/2025 20:46, Alexei Olkhovskii
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CH4PR08MB1051078FA9DA27F54C44E0F328D67A@CH4PR08MB10510.namprd08.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style>@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Aptos",sans-serif;
color:#0F4761;}span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">> </span><span style="font-size:12.0pt">This may be an issue with the
reserved stack area. There was work done in JDK 9 via JEP
270 [1] but I think it needs to be looked at again.<br>
<br>
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Perhaps <a href="https://bugs.openjdk.org/browse/JDK-8318888" moz-do-not-send="true" class="moz-txt-link-freetext">
https://bugs.openjdk.org/browse/JDK-8318888</a> is also
relevant.</span></p>
</div>
</blockquote>
<br>
Yes, there are a few reports of issues when continuing after SOE.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CH4PR08MB1051078FA9DA27F54C44E0F328D67A@CH4PR08MB10510.namprd08.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But
regardless of the reason the other thread is holding the
lock, don’t you think the socket timeout should be respected
for read(), connect(), etc?</span></p>
</div>
</blockquote>
<br>
The connect method is only allowed once. It would be strange to
create an unconnected Socket and then attempt to have 2 threads
invoke connect. The second attempt must fail with SocketException
(it will be "Connection in progress" or "Socket closed"). You are
right that the second attempt will block, maybe beyond the connect
timeout it specifies, before it throws the SocketException. I don't
think this is worth spending time on as there is impossible for the
second connect to succeed.<br>
<br>
It's hard to know if there if there is a case where concurrent reads
from the same TCP/socket stream make sense. At one point it was
possible to have a Socket to a UDP socket but that mis-feature is
deprecated a long time ago. If several threads are reading from the
same stream then it requires coordination at a higher level,
something that understands the protocol, meaning the lock contention
will be further up the stack. If there is a protocol where it's
possible to do something sensible when reading subsets of bytes, and
with different timeouts, or code handling SocketTimeoutException
then maybe your point could be looked. For now, I think the issue
here is the "lock corruption" and we need to understand this a bit
more. I'd prefer not use that to justify doing something to help a
workaround when it does happen.<br>
<br>
-Alan<br>
</body>
</html>