Update to Cats Effect v3.5.0-RC2

[armanbilge]

1. Fixes for new async cancellation semantics. Also plug some resource leaks.
2. Prefer performance-enhanced Mutex to Semaphore(1)
3. Prefer flatModify to modify(...).flatten, fixes at least a few cancellation-related bugs

[armanbilge]

Some possibly concerning, non-deterministic JVM failures.

==> X fs2.StreamInterruptSuite.3 - constant stream  31.001s java.util.concurrent.TimeoutException: test timed out after 31 seconds
==> X fs2.StreamInterruptSuite.4 - interruption of constant stream with a flatMap  31.001s java.util.concurrent.TimeoutException: test timed out after 31 seconds
==> X fs2.StreamInterruptSuite.5 - interruption of an infinitely recursive stream  31.002s java.util.concurrent.TimeoutException: test timed out after 31 seconds
  + 6 - interruption of an infinitely recursive stream that never emits 0.582s
==> X fs2.StreamInterruptSuite.7 - interruption of an infinitely recursive stream that never emits and has no eval  31.0s java.util.concurrent.TimeoutException: test timed out after 31 seconds
  + 8 - interruption of a stream that repeatedly evaluates 0.505s
==> X fs2.StreamInterruptSuite.9 - interruption of the constant drained stream  31.001s java.util.concurrent.TimeoutException: test timed out after 31 seconds

https://github.com/typelevel/fs2/actions/runs/4176988548/jobs/7234274942#step:11:1431

Those tests look like this:

fs2/core/shared/src/test/scala/fs2/StreamInterruptSuite.scala

Lines 61 to 69 in 1531919

	test("3 - constant stream") {
	val interruptSoon = Stream.sleep_[IO](20.millis).compile.drain.attempt
	Stream
	.constant(true)
	.interruptWhen(interruptSoon)
	.compile
	.drain
	.replicateA(interruptRepeatCount)
	}

So basically they are testing the ability for concurrent interruption of CPU-bound work.

[armanbilge]

I was able to replicate locally by adding Test / javaOptions += "-XX:ActiveProcessorCount=2" so that it's like CI ...

[djspiewak]

Hmm…

[armanbilge]

Update to those following along here: we've traced this to a bug in WorkerThread, where after a timer fires and re-enqueues a fiber in the local queue, the worker still assumes its local queue is empty and continues trying to (unsuccessfully) steal work from elsewhere.

Breadcrumbs:

• Rare runtime condition in which timers are lost cats-effect#3422
• Fixed issues in the timer handling state machine integration cats-effect#3432