On Wed, 20 Jan 2021 15:34:21 GMT, Claes Redestad wrote:
>> eirbjo has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> As a part of the rename from "canonize" to "canonicalize", doCanonize
>> should also be renamed. This was an oversight in
> By moving string splitting and concatenation into the canonizeString utility,
> we can defer allocation until we determine that canonization is required.
> This saves two string allocations and a string concat for the common case
> where canonization is not required.
>
> As a refactoring,
On Wed, 20 Jan 2021 15:32:13 GMT, Claes Redestad wrote:
>> eirbjo has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> As a part of the rename from "canonize" to "canonicalize", doCanonize
>> should also be renamed. This was an oversight in
On Wed, 20 Jan 2021 15:25:18 GMT, eirbjo
wrote:
> By moving string splitting and concatenation into the canonizeString utility,
> we can defer allocation until we determine that canonization is required.
> This saves two string allocations and a string concat for the common case
> where
By moving string splitting and concatenation into the canonizeString utility,
we can defer allocation until we determine that canonization is required. This
saves two string allocations and a string concat for the common case where
canonization is not required.
As a refactoring, move
On Wed, 20 Jan 2021 14:49:05 GMT, Daniel Fuchs wrote:
> My understanding is that read will read a full datagram (or nothing) and
> write will write a full datagram (or nothing). Indeed a datagram is the
> smallest unit that can be read or written on a UDP channel. Two calls to
> write() will
On Wed, 20 Jan 2021 13:40:51 GMT, Mark Sheppard wrote:
>> LGTM. Thanks Patrick for taking this on!
>
> This response maybe a bit of overkill or overthinking, but bear with me and
> apologies in advance!!
> I think some of the additions have a few (theoretical) consequences - the
> read buffer
On Wed, 20 Jan 2021 12:53:34 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could someone please review my fix for JDK-8259628:
>> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
>> intermittently' ?
>>
>> `AsynchronousSocketChannelNAPITest` is failing intermittently on
On Wed, 20 Jan 2021 11:52:17 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my fix for JDK-8259628:
> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
> intermittently' ?
>
> `AsynchronousSocketChannelNAPITest` is failing intermittently on
Hi,
Could someone please review my fix for JDK-8259628:
'`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
intermittently' ?
`AsynchronousSocketChannelNAPITest` is failing intermittently on Linux due to a
race condition caused by not correctly waiting for the result
10 matches
Mail list logo
