<div dir="ltr">What is the deal here? You should be able to have millions of connections or what are you doing with this whole thing?<div><br></div><div><a href="https://blog.whatsapp.com/1-million-is-so-2011">1 million is so 2011 - WhatsApp Blog</a></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2025 at 5:47 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 30/01/2025 11:41 am, David Holmes wrote:<br>
> On 30/01/2025 4:20 am, Andrew Haley wrote:<br>
>> On 1/29/25 16:58, Matthew Swift wrote:<br>
>>><br>
>>> Given that scaling IO to millions of concurrent IO bound tasks was <br>
>>> one of the key motivations for vthreads, it seems a bit surprising to <br>
>>> me that a basic concurrency building block of many applications is <br>
>>> constrained to 64K concurrent accesses. Are you aware of this <br>
>>> limitation and its implications?<br>
>><br>
>>           * Lock state is logically divided into two unsigned shorts:<br>
>>           * The lower one representing the exclusive (writer) lock <br>
>> hold count,<br>
>>           * and the upper the shared (reader) hold count.<br>
>><br>
>> I have no love at all for arbitrary limits, and this certainly sounds <br>
>> like<br>
>> one. And you may be right that these days it's something that might <br>
>> happen<br>
>> in real-world deployments.<br>
> <br>
> More of a practical limit than an "arbitrary" one.  Noone was going to <br>
> hit 64K contending platform threads. And requiring general 64-bit atomic <br>
> operations back when 32-bit was still very much mainstream, would not <br>
> have produced an efficient implementation.<br>
> <br>
>> Here's a suggestion: it shouldn't be madly difficult to rewrite the <br>
>> code so<br>
>> that instead of an int split into two unsigned shorts, it uses a long <br>
>> split<br>
>> into two unsigned ints. Why not give that a try, and see what happens?<br>
>> Building OpenJDK on most platforms is fairly straightforward these days.<br>
> <br>
> Simply rebasing to extend AbstractLongQueuedSynchronizer instead of AQS, <br>
> as others have suggested, may "just work".<br>
<br>
Though I meant to add that I think you will run into other scalability <br>
issues once you are dealing with such large numbers of threads.<br>
<br>
David<br>
-----<br>
<br>
> Cheers,<br>
> David<br>
> <br>
>> Once you have some information about how well it works in practice, it <br>
>> may<br>
>> be appropriate to talk to Doug Lea, the author, about removing the <br>
>> limitation.<br>
>><br>
> <br>
<br>
</blockquote></div>