Bump cats-effect_2.12 from 0.4 to 3.3.5

[dependabot]

Bumps cats-effect_2.12 from 0.4 to 3.3.5.

Release notes

Sourced from cats-effect_2.12's releases.

v3.3.5

This is the twentieth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas. Scalafixes are available and should be automatically applied by Scala Steward if relevant.

User-Facing Pull Requests

• #2776 – Faster runnables on the WSTP (@​vasilmkd)
• #2769 – Simplify the transfer of WorkerThread data structures when blocking (@​vasilmkd)
• #2743 – Workaround for lampepfl/dotty#14240 (@​armanbilge)
• #2746 – Only run the thread logger if forked (@​vasilmkd)
• #2733, #2752 – Documentation fixes and improvements (@​TimWSpence, @​jmgimeno)

Special thanks to all of you!

v3.3.4

This is the nineteenth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas. Scalafixes are available and should be automatically applied by Scala Steward if relevant.

User-Facing Pull Requests

• #2735 – Run blocking code on the compute pool more carefully (@​vasilmkd)
• #2724 – Handle interruption around blocking waits (@​vasilmkd)
• #2729 – Concurrent.memoize: be more careful with the result (@​durban)
• #2731 – Invoke process.exit within a Try in IOApp.js (@​armanbilge)
• #2719 – Attempt to detect host environments (like unforked sbt) (@​djspiewak)
• #2721 – Leaked fiber test for JS IOApp (@​armanbilge)
• #2714 – Set the callback unsafely without memory barriers and allocations (@​vasilmkd)

Special thanks and appreciation to all of you!

v3.3.3

This is the eighteenth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas. Scalafixes are available and should be automatically applied by Scala Steward if relevant.

This release contains a fix for a regression introduced in 3.3.0 related to IOApps which exit with non-fatal errors when run from within Sbt with fork set to false. In that scenario, the runtime worker threads would end up hung in a busy-wait loop and eat up all available CPU despite returning control to the Sbt shell. Despite this fix, it is still recommended that you set run / fork := true in Sbt to work around other bugs in Sbt itself (specifically related to both Ctrl-C and System.exit suppression).

User-Facing Pull Requests

• #2705 – Detect sbt thread cleaner and terminate workers (@​djspiewak)
• #2707 – Hard exit in Node.js IOApp (@​armanbilge)

Thank you so much!

v3.3.2

This is the seventeenth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas. Scalafixes are available and should be automatically applied by Scala Steward if relevant.

This patch release focuses primarily on performance improvements in two major areas: blocking/interruptible and suspended fiber tracking.

In the former area, the Cats Effect fiber runtime has long had support for the scala.concurrent.blocking construct within any code which is scheduled on its worker threads. When such a block is hit, the runtime takes it as a signal that it is about to lose a functioning worker thread and thus spawns a new one, seamlessly putting it into rotation to ensure the pool is not starved by the current worker thread being blocked. This trick works very well, but wasn't particularly recommended in user code because the performance was worse than the native IO.blocking operation.

In this release, Vasil has changed the behavior of the pool to seamlessly shift worker state when a blocking section is hit, effectively morphing another thread into the exact state as the now-blocked thread. Additionally, spare threads constructed when blocking operations are hit are now cached for one minute before being cleaned up if still idle, ensuring that they're still around if a subsequent blocking operation is hit in short order.

These improvements, taken together, mean that scala.concurrent.blocking inside of delay is actually faster than the IO.blocking operation by a significant margin, meaning that we can reap immediate performance benefits by converting IO.blocking and IO.interruptible to use this native mechanism rather than an ancillary thread pool.

... (truncated)

Commits

• a30a464 Merge pull request #2776 from vasilmkd/faster-runnables
• 20dab37 Add an EC.global runnable scheduling benchmark for comparison
• 08ba24e Use the new constructor in WSTP
• 688409b A new IOFiber constructor from a runnable
• 6138429 Add the option to execute runnables instead of the run loop
• f73f33b Move all data structure allocations to the primary constructor
• 5682e32 Relax the type of resumeIO
• 0bdeaea Merge pull request #2769 from vasilmkd/data-structures-in-pool
• bb0d185 Add Scala 3 specific exclusions
• 6a741d7 Add mima exclusions for the deleted classes
• 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 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)

[dependabot]

Superseded by #208.