search

joffrey-bion / krossbow

A Kotlin multiplatform coroutine-based STOMP client over websockets, with built-in conversions.
MIT License
189 stars 14 forks source link

Bump kotlinx-io from 0.4.0 to 0.5.0 #534

Closed dependabot[bot] closed 1 month ago

dependabot[bot] commented 1 month ago

Bumps kotlinx-io from 0.4.0 to 0.5.0. Updates org.jetbrains.kotlinx:kotlinx-io-core from 0.4.0 to 0.5.0

Release notes

Sourced from org.jetbrains.kotlinx:kotlinx-io-core's releases.

v0.5.0

Features

  • Provided an API allowing direct access to Buffer and Segment internals #135, #166

    The API is unsafe, delisted from public docs and requires explicit opt-in. It's recommended to avoid this API unless you're working on integration with other APIs (like, java.nio or io_uring, for example).

  • Improved the way segment pooling is working on JVM #352

    Now sharing a segment won't make an original segment and all its copies recyclable. Instead, the last remaining copy will be placed back into the pool when recycled. Segments are no longer allocated or lost when taking or recycling a segment from a pool under a high contention due to concurrent requests. The size of the segment pool on the JVM could now be statically configured by setting a system property kotlinx.io.pool.size.bytes.

Thanks to @​bjhham, @​e5l, @​lppedd, @​qwwdfsad, @​shanshin, and @​whyoleg for their participation in this release release!

Changelog

Sourced from org.jetbrains.kotlinx:kotlinx-io-core's changelog.

0.5.0

Published 12 July 2024

Features

  • Provided an API allowing direct access to Buffer and Segment internals #135, #166

    The API is unsafe, delisted from public docs and requires explicit opt-in. It's recommended to avoid this API unless you're working on integration with other APIs (like, java.nio or io_uring, for example).

  • Improved the way segment pooling is working on JVM #352

    Now sharing a segment won't make an original segment and all its copies recyclable. Instead, the last remaining copy will be placed back into the pool when recycled. Segments are no longer allocated or lost when taking or recycling a segment from pool under a high contention due to concurrent requests. Size of the segment pool on the JVM could now be statically configured by setting a system property kotlinx.io.pool.size.bytes.

Commits
  • c2ff370 Release 0.5.0
  • be2bfca SegmentPool improvements (#352)
  • 3eb8117 Correctly split head segment (#350)
  • cc82d10 Update BCV to 0.15.0-Beta.3 and regenerate dumps (#349)
  • 2e2f71a Fix incorrect atomic updates (#348)
  • 8d9c36c Minor cleanup: postpone nullable ref null-check
  • 31a40ed [Unsafe API 3/5] Implement Unsafe API to iterate over segments and access its...
  • 72fa4ee [PR 2/5] Introduce unsafe API for bulk read/write ops (#334)
  • 6f95a1b [Unsafe API 1/5] Organize Buffer's segments as a regular list (#332)
  • e0d5fa9 Avoid unnecessary checks when calling readCodePointValue on Buffer (#343)
  • Additional commits viewable in compare view


Updates org.jetbrains.kotlinx:kotlinx-io-bytestring from 0.4.0 to 0.5.0

Release notes

Sourced from org.jetbrains.kotlinx:kotlinx-io-bytestring's releases.

v0.5.0

Features

  • Provided an API allowing direct access to Buffer and Segment internals #135, #166

    The API is unsafe, delisted from public docs and requires explicit opt-in. It's recommended to avoid this API unless you're working on integration with other APIs (like, java.nio or io_uring, for example).

  • Improved the way segment pooling is working on JVM #352

    Now sharing a segment won't make an original segment and all its copies recyclable. Instead, the last remaining copy will be placed back into the pool when recycled. Segments are no longer allocated or lost when taking or recycling a segment from a pool under a high contention due to concurrent requests. The size of the segment pool on the JVM could now be statically configured by setting a system property kotlinx.io.pool.size.bytes.

Thanks to @​bjhham, @​e5l, @​lppedd, @​qwwdfsad, @​shanshin, and @​whyoleg for their participation in this release release!

Changelog

Sourced from org.jetbrains.kotlinx:kotlinx-io-bytestring's changelog.

0.5.0

Published 12 July 2024

Features

  • Provided an API allowing direct access to Buffer and Segment internals #135, #166

    The API is unsafe, delisted from public docs and requires explicit opt-in. It's recommended to avoid this API unless you're working on integration with other APIs (like, java.nio or io_uring, for example).

  • Improved the way segment pooling is working on JVM #352

    Now sharing a segment won't make an original segment and all its copies recyclable. Instead, the last remaining copy will be placed back into the pool when recycled. Segments are no longer allocated or lost when taking or recycling a segment from pool under a high contention due to concurrent requests. Size of the segment pool on the JVM could now be statically configured by setting a system property kotlinx.io.pool.size.bytes.

Commits
  • c2ff370 Release 0.5.0
  • be2bfca SegmentPool improvements (#352)
  • 3eb8117 Correctly split head segment (#350)
  • cc82d10 Update BCV to 0.15.0-Beta.3 and regenerate dumps (#349)
  • 2e2f71a Fix incorrect atomic updates (#348)
  • 8d9c36c Minor cleanup: postpone nullable ref null-check
  • 31a40ed [Unsafe API 3/5] Implement Unsafe API to iterate over segments and access its...
  • 72fa4ee [PR 2/5] Introduce unsafe API for bulk read/write ops (#334)
  • 6f95a1b [Unsafe API 1/5] Organize Buffer's segments as a regular list (#332)
  • e0d5fa9 Avoid unnecessary checks when calling readCodePointValue on Buffer (#343)
  • Additional commits viewable in compare view


Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)