Cancellation model still feels wrong

[alexandru]

Hi all,

Sorry for reviving a dead discussion 🙂 but the feeling that the current behavior is wrong never went away.

I was prepared to submit a bug report, until I realized that Cats-Effect works as intended. For instance, this doesn't work as expected, the script will terminate after 30 seconds, instead of 3:

#!/usr/bin/env -S scala-cli shebang -q

//> using scala "2.13.9"
//> using lib "org.typelevel::cats-effect::3.3.12"
//> using lib "org.apache.commons:commons-text:1.9"

import cats.effect.{ExitCode, IO, IOApp}
import cats.syntax.all._
import java.util.concurrent.atomic.AtomicBoolean
import java.util.concurrent.CountDownLatch
import scala.concurrent.duration._

object Main extends IOApp {
  def run(args: List[String]): IO[ExitCode] = {
    val task = IO {
      new CountDownLatch(1)
    }.bracket { isActive =>
      // This shouldn't be cancelable on purpose
      val task1 = 
        IO.blocking { 
          try {
            isActive.await()
          } catch {
            case e: java.lang.InterruptedException =>
              println("ERROR: Cancelled task1!")
              throw e
          }
        }
      val task2 = IO.sleep(30.seconds) *> IO {
        isActive.countDown()
      }
      // Parallel execution
      (task1, task2).parMapN((_, _) => ExitCode.Success)
    } { isActive =>
      IO {
        println("Cancelling everything...")
        isActive.countDown()
      }
    }

    // Doesn't work ;-)
    task.timeout(3.seconds)
  }
}

This program doesn't work by design because bracket's release cannot be executed until use is either complete or cancelled. However, I'd like to give Kotlin's Coroutines as a sample that does work as expected:

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 17+
//KOTLIN 1.7.20
//DEPS org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withContext
import kotlinx.coroutines.withTimeout
import java.util.concurrent.CountDownLatch
import kotlin.time.Duration.Companion.seconds

suspend fun run() =
  coroutineScope {
    val isActive = CountDownLatch(1)
    try {
      // `launch` does async execution (Cats-Effect's `start`)
      // This task should be uncancellable on purpose:
      val task1 = launch {
        withContext(Dispatchers.IO) {
          try {
            isActive.await()
          } catch (e: InterruptedException) {
            println("ERROR: task1 cancelled!")
            throw e
          }
        }
      }
      val task2 = launch {
        delay(30.seconds)
        isActive.countDown()
      }
      // Tasks running in parallel, awaiting their completion to proceed:
      task1.join()
      task2.join()
      println("Done!")
    } finally {
      println("Stopping everything...")
      isActive.countDown()
    }
  }

fun main() = runBlocking {
  withTimeout(3.seconds) {
    run()
  }
}

Looking at these 2 pieces of code, the Kotlin sample is more clear, it does the right thing (cancels after exactly 3 seconds, and releases any resources, no leaks), and I can understand it without needing special education. For the Cats-Effect sample, if someone asked — what is the equivalent of try-finally or of try-with-resources, I'd say that bracket is, but that isn't true, as exemplified by the above program.

---

This example is a minified version of a bigger example that happens in real-life. Here's the Kotlin code that, again, does the right thing:

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 17+
//KOTLIN 1.7.20
//DEPS org.apache.commons:commons-text:1.9
//DEPS org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.async
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.runInterruptible
import kotlinx.coroutines.withContext
import kotlinx.coroutines.withTimeout
import org.apache.commons.text.StringEscapeUtils
import java.nio.charset.StandardCharsets.UTF_8
import java.nio.file.Path
import kotlin.time.Duration.Companion.seconds

data class CommandResult(
  val exitCode: Int,
  val stdout: String,
  val stderr: String,
)

/**
 * Executes a program. This needs to be a valid path on the
 * file system.
 *
 * See [executeShellCommand] for the version that executes
 * `/bin/sh` commands.
 */
suspend fun executeCommand(executable: Path, vararg args: String): CommandResult =
  // Blocking I/O should use threads designated for I/O
  withContext(Dispatchers.IO) {
    val cmdArgs = listOf(executable.toAbsolutePath().toString()) + args
    val proc = Runtime.getRuntime().exec(cmdArgs.toTypedArray())
    try {
      // Concurrent execution ensures the stream's buffer doesn't
      // block processing when overflowing
      val stdout = async {
        runInterruptible(Dispatchers.IO) {
          // That `InputStream.read` doesn't listen to thread interruption
          // signals; but for future development it doesn't hurt
          String(proc.inputStream.readAllBytes(), UTF_8)
        }
      }
      val stderr = async {
        runInterruptible(Dispatchers.IO) {
          String(proc.errorStream.readAllBytes(), UTF_8)
        }
      }
      CommandResult(
        exitCode = runInterruptible(Dispatchers.IO) { proc.waitFor() },
        stdout = stdout.await(),
        stderr = stderr.await()
      )
    } finally {
      proc.destroy()
    }
  }

/**
 * Executes shell commands.
 *
 * WARN: command arguments need be given explicitly because
 * they need to be properly escaped.
 */
suspend fun executeShellCommand(command: String, vararg args: String): CommandResult =
  executeCommand(
    Path.of("/bin/sh"),
    "-c",
    (listOf(command) + args)
      .map(StringEscapeUtils::escapeXSI)
      .joinToString(" ")
  )

fun main(vararg args: String) = runBlocking {
  val r = withTimeout(3.seconds) {
    executeShellCommand("sleep", "30")
  }
  System.out.print(r.stdout)
  System.err.print(r.stderr)
  System.exit(r.exitCode)
}

Converting this sample to Cats-Effect is surprisingly difficult, with the naive translation being wrong, for the reasons stated above:

def executeCommand(executable: Path, args: String*): IO[CommandResult] =
    IO.blocking {
      val commandArgs = executable.toAbsolutePath.toString +: args
      Runtime.getRuntime.exec(commandArgs.toArray)
    }
    .bracket { proc =>
      // These aren't actually "interruptible", because that InputStream#read 
      // isn't interruptible — only way to stop these is `proc.destroy()`
      val awaitStdout = IO.interruptible {
        new String(proc.getInputStream.readAllBytes(), UTF_8)
      }
      val awaitStderr = IO.interruptible {
        new String(proc.getErrorStream.readAllBytes(), UTF_8)
      }
      // This is actually cancellable via thread interruption
      val awaitReturnCode = IO.interruptible { 
        proc.waitFor()
      }
      // Executing all 3 tasks in parallel, awaiting their result
      (awaitReturnCode, awaitStdout, awaitStderr).parMapN {
        (code, stdout, stderr) =>
          CommandResult(code, stdout, stderr)
      }
    } { proc =>
      // Finally clause ...
      IO.blocking {
        println("Destroying process")
        proc.destroy() 
      }
    }

Now that I think of it, I can probably do awaitStdout.start and then fiber.join. Which may work, but that's only because (AFAIK) child fibers don't get cancelled if the parent fiber was cancelled.

So what's the right translation of that Kotlin sample? Anything obvious that I'm not seeing?

[SystemFw]

I think it's worth pointing out that you can argue the kotlin model is also broken: if you nest a couple of try/finally with those semantics, because you don't backpressure on finalisers, you won't be able to guarantee releasing in reverse order of acquisition, and might have use-after-free bugs, and engineering a solution to that into Kotlin's semantics is super hard.

Btw, this translation of your initial example to pure CE could help other people reading:

object Main1 extends IOApp.Simple {
  def run: IO[Unit] = {
    val task =
      IO.deferred[Unit]
        .bracket { await =>
          val task1 =
            await.get.uncancelable
              .onCancel(IO.println("ERROR: Cancelled task1!"))

          val task2 = IO.sleep(30.seconds) >> await.complete(()).void

          (task1, task2).parTupled.void
        } { await =>
          IO.println("cancelling everything") >> await.complete(()).void
        }

    task.timeout(3.seconds)
  }
}

[alexandru]

I think it's worth pointing out that you can argue the kotlin model is also broken: if you nest a couple of try/finally with those semantics, because you don't backpressure on finalisers, you won't be able to guarantee releasing in reverse order of acquisition, and might have use-after-free bugs, and engineering a solution to that into Kotlin's semantics is super hard.

I don't think it's so clear that the model is broken, and would really appreciate an example — if you have the time and inclination, of course.

In the given sample, it can be argued that:

1. The main fiber is perfectly fine, since there you have the classic try-finally, and cancellation is similar to a thrown exception;
2. If the main fiber nests try-finally statements, then a natural back-pressure happens when closing resources (similar to Cats-Effect);
3. The forked fiber is concurrent, therefore it goes without saying that the resources captured from the main fiber have to be thread-safe — and in my sample, they are thread-safe — that InputStream has to be thread-safe otherwise I couldn't read from it, and of course it can be closed concurrently;
4. The cancellation signal does go out to the forked fiber first, but it doesn't back-pressure on it before cancelling the main fiber — and it makes sense, since the fiber is concurrent, it's fair game;
5. There is back-pressuring happening here ... the execution does not continue until the main fiber AND all its children are canceled;

Sorry for the Kotlin samples, but this does well to exemplify (executable via JBang):

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 17+
//KOTLIN 1.7.20
//DEPS org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.runInterruptible
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withContext
import kotlinx.coroutines.withTimeout
import java.util.concurrent.CountDownLatch
import kotlin.time.Duration.Companion.seconds

suspend fun run() =
  coroutineScope {
    val isActive = CountDownLatch(1)
    try {
      // This is now cancelable
      val task1 = launch {
        runInterruptible(Dispatchers.IO) {
          try {
            isActive.await()
          } catch (e: InterruptedException) {
            println("Cancelling forked fiber...")
            Thread.sleep(4000) // to see how back-pressure works
            println("Cancelled forked fiber!")
            throw e
          }
        }
      }
      val task2 = launch {
        delay(30.seconds)
        isActive.countDown()
      }
      task1.join()
      task2.join()
      println("Done!")
    } finally {
      isActive.countDown()
      println("Cancelled main fiber!")
    }
  }

fun main() = runBlocking {
  try {
    withTimeout(3.seconds) {
      run()
    }
  } finally {
    println("Exiting process!")
  }
}

Which outputs:

Cancelling forked fiber...
Cancelled main fiber!
Cancelled forked fiber!
Exiting process!

Note that I am not convinced that I am right, so I'd appreciate a sample that makes a lot of sense in Cats-Effect and doesn't work in Kotlin.

[SystemFw]

Doesn't

The cancellation signal does go out to the forked fiber first, but it doesn't back-pressure on it before cancelling the main fiber — and it makes sense, since the fiber is concurrent, it's fair game;

Bring you back to the issues with:
#267

(fwiw, Haskell's base model is to not backpressure, and it's considered broken, and the recommended async package does backpressure)

[alexandru]

@SystemFw I should have prefixed my initial message with a …

I now believe that back-pressuring cancellation is good, however, while using Cats-Effect's API, I'm still bumping into cases that are surprising; it's not the general concept that I have a problem with, but rather the API (or how I choose to use it, which may also indicate bad defaults).

Doesn't ... bring you back to the issues with:
#267

Yes, and no. This is a more nuanced approach — Kotlin's implementation does not have issues with inner try-finally statements (the equivalent for our brackets), because release is not concurrent with use. All finally statements are back-pressured, as long as they happen on the same (logical) thread.

To explain it in terms of Cats-Effect, consider this code:

#!/usr/bin/env -S scala-cli shebang -q

//> using scala "2.13.9"
//> using lib "org.typelevel::cats-effect::3.3.12"

import cats.effect.{ExitCode, IO, IOApp}
import cats.syntax.all._
import scala.concurrent.duration._

object Main extends IOApp {
  def run(args: List[String]): IO[ExitCode] = {
    val scope = IO.unit.bracket { resource1 =>  
      IO.unit.bracket { resource2 =>
        val task = (IO(println("(0) Starting forked task")) *> IO.never)
          .onCancel(
            IO(println("(1) Cancelling forked task...")) *> 
              IO.sleep(3.seconds) *> 
              IO(println("(2) Cancelled forked task"))
          )
        for {
          _ <- task.start
          _ <- IO.never[Unit]
        } yield ()
      } { resource2 =>
        IO(println("(1) Releasing resource2...")) *>
          IO.sleep(1.seconds) *> 
          IO(println("(2) Released resource2"))
      }
    } { resource1 =>
      IO(println("(1) Releasing resource1...")) *>
        IO.sleep(1.seconds) *> 
        IO(println("(2) Released resource1"))
    }

    for {
      _ <- scope.timeout(1.second).attempt
      _ <- IO(println("(3) Continuing..."))
    } yield ExitCode.Success
  }
}

The output of this, as you'd expect, at the moment of writing:

(0) Starting forked task
(1) Releasing resource2...
(2) Released resource2
(1) Releasing resource1...
(2) Released resource1
(3) Continuing...

That forked task is not canceled. And if we replace that .start with .background, here's what happens:

//...
task.background.use { _ =>
  IO.never[Unit]
}
//...

(0) Starting forked task
(1) Cancelling forked task...
(2) Cancelled forked task
(1) Releasing resource2...
(2) Released resource2
(1) Releasing resource1...
(2) Released resource1
(3) Continuing...

What happens is that the cancellation of the forked task is not concurrent with the resource release. This is unlike what would happen in Kotlin. Which would be this:

(0) Starting forked task
(1) Cancelling forked task...
(1) Releasing resource2...
(2) Released resource2
(1) Releasing resource1...
(2) Released resource1
(2) Cancelled forked task
(3) Continuing...

Things to notice:

1. cancellation of the forked task happens, implicitly, when its parent gets cancelled;
2. cancellation of the forked task is concurrent;
3. releasing those 2 resources, one after another, is not concurrent, so there's back-pressuring;
4. there's also back-pressuring on the last line — execution cannot continue until everything gets cancelled, parent fiber and its children;

Here's the code to reproduce this behavior:

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 17+
//KOTLIN 1.7.20
//DEPS org.apache.commons:commons-text:1.9
//DEPS org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4

import kotlinx.coroutines.*
import kotlin.time.Duration.Companion.seconds

suspend fun scope() = coroutineScope {
  try { // resource1 =>
    try { // resource2 =>
      // task fork
      launch {
        runInterruptible(Dispatchers.IO) {
          println("(0) Starting forked task")
          try {
            Thread.sleep(10000)
          } catch (e: InterruptedException) {
            println("(1) Cancelling forked task...")
            Thread.sleep(3000)
            println("(2) Cancelled forked task")
          }
        }
      }
      delay(100.seconds)
    } finally {
      println("(1) Releasing resource2...")
      Thread.sleep(1000)
      println("(2) Released resource2")
    }
  } finally {
    println("(1) Releasing resource1...")
    Thread.sleep(1000)
    println("(2) Released resource1")
  }
}

fun main() = runBlocking {
  try {
    withTimeout(3.seconds) { scope() }
  } catch (e: TimeoutCancellationException) {}
  println("(3) Continuing...")
}

[SystemFw]

This is unlike what would happen in Kotlin. Which would be this:

(0) Starting forked task
(1) Cancelling forked task...
(1) Releasing resource2...
(2) Released resource2
(1) Releasing resource1...
(2) Released resource1
(2) Cancelled forked task
(3) Continuing...

Well, but this can result in use-after-free during the finalisation of forked task. Now, in the past you've said things along the lines of "that's already concurrent, so that's fine", but I disagree. This model forces you to write concurrency aware finalisation logic, which the cats-effect model does, by and large, not force you to.

cancellation of the forked task happens, implicitly, when its parent gets cancelled;

This to me is an orthogonal matter, as in: if you ignore the difference above in the concurrency between release and forked task cancellation, is the structured concurrency in Kotlin meaningfully different from background or a IOcoroutineScope combinator with an implicit Supervisor => ?

[SystemFw]

As for your semantics, I'd do

object Main1 extends IOApp.Simple {
  def run: IO[Unit] = {
    val task =
      alexBracket(
        IO.deferred[Unit]
      )(await => IO.println("cancelling everything") >> await.complete(()).void) {
        await =>
          val task1 =
            await.get.uncancelable
              .onCancel(IO.println("ERROR: Cancelled task1!"))

          val task2 = IO.sleep(30.seconds) >> await.complete(())

          (task2, task1).parTupled.void
      }

    task.timeout(3.seconds)
  }

  def alexBracket[A, B](acquire: IO[A])(release: A => IO[Unit])(
      f: A => IO[B]
  ): IO[B] =
    IO.uncancelable { poll =>
      acquire.flatMap { a =>
        f(a).start.flatMap { fiber =>
          poll(fiber.joinWithNever).guarantee(release(a))
        }
      }
    }
}

[info] running Main1 
cancelling everything
[error] java.util.concurrent.TimeoutException: 3 seconds
[error] 	at timeout @ Main1$.run(Playground.scala:41)
[error] 	at timeout @ Main1$.run(Playground.scala:41)
[error] 	at timeout @ Main1$.run(Playground.scala:41)
[error] 	at main$ @ Main1$.main(Playground.scala:25)

[alexandru]

@armanbilge yes, Supervisor and .background are good ideas, but it's a band-aid for what should have been implicit behavior.

start should tie forked fibers to a (configurable) scope, that is by default the current fiber, and when that scope gets cancelled (or ends in error), it should cancel all its forked fibers too. Also, the cancelation signal of the main fiber should not be back-pressured on the cancelation of the forked fibers.

In general, libraries should do the right thing by default. If it takes too much domain-specific knowledge to do the right thing, it's not a good design. To be explicit about it:

(1) "Fire and forget" is definitely not a good default. It should take real effort to do it (i.e., an explicit configuration that specifies a fork from the “global” fiber, aka the main thread);

(2) Back-pressuring the release in bracket due to forked fibers (that are then joined) isn't a good default either, although this one may be harder to change (or even agree on).

What makes this difficult in Cats-Effect is that there is a difference between:

(task1, task2).parMapN(_ + _)

And ...

for {
  f <- task1.start
  r1 <- task2
  r2 <- f.join
} yield r1 + r2

The later should actually be the preferred API for most people, IMO, but isn't, because Cats-Effect makes it by default inherently unsafe, due to how start behaves.

[alexandru]

NOTE — there is a lot of background in this claim (that forked fibers should be cancelled by their parent).

It's akin to memory management in C or C++. The component / code that allocates memory is also responsible for its deallocation. It's how RAII happened, as it's much easier to simply deallocate stuff when it goes out of its current lexical scope.

Resource is an explicit scope, but in this case it's an insufficient one.

[SystemFw]

Fyi, I think this is a valuable discussion but I'm struggling to follow it a bit, so if you see me disappear is to try and find time to read things properly. The two things I'm confused about are:
A) I thought the discussion was about not backpressuring on finalisers, rather than structured concurrency, so I'm trying to figure out the relationship here. I also don't fully follow how coroutineScope is that different/better than background.use.
B) I'm not familiar enough with the finer details of the kotlin model to easily follow your examples :)

[alexandru]

@SystemFw The discussion is about being surprised. As I should have explicitly stated, I now believe back-pressuring finalizers is good, however I don't like surprises in common API use, and maybe we can talk about borrowing some ideas from the “structured concurrency” approach.

On the difference with background.use, please see my comment above link.

[SystemFw]

As I should have explicitly stated, I now believe back-pressuring finalizers is good

ah sorry for misunderstanding, that definitely helps. I had missed your other comment, I'll try and have a look at that today.

maybe we can talk about borrowing some ideas from the “structured concurrency” approach.

Definitely up for that, though I wonder if changing the behaviour of start can even be on the cards in the 3.x lineage, even assuming we'd all agree to it

[alexandru]

@SystemFw Here is another variation, and for this one I really think Cats-Effect could do a better job by cancelling children fibers when the main fiber gets cancelled:

#!/usr/bin/env -S scala-cli shebang -q

//> using scala "2.13.9"
//> using lib "org.typelevel::cats-effect::3.3.12"
//> using lib "org.apache.commons:commons-text:1.9"

import cats.effect.{ExitCode, IO, IOApp}
import cats.syntax.all._
import java.util.concurrent.atomic.AtomicBoolean
import java.util.concurrent.CountDownLatch
import scala.concurrent.duration._

object Main extends IOApp {
  def run(args: List[String]): IO[ExitCode] = {
    val task = IO {
      new CountDownLatch(1)
    }.bracket { isActive =>
      // This is now cancelable
      val task1 = 
        IO.interruptible { 
          try {
            isActive.await()
          } catch {
            case e: java.lang.InterruptedException =>
              println("Cancelled task1 (1)")
              throw e
          }
        }.onCancel {
          IO(println("Cancelled task1 (2)"))
        }
      val task2 = IO.sleep(30.seconds) *> IO {
        isActive.countDown()
      }
      // Using fiber.start instead of parMap
      for {
        fiber1 <- task1.start
        _ <- task2
        _ <- fiber1.joinWithNever
      } yield {
        ExitCode.Success
      }
    } { isActive =>
      IO {
        println("Cancelling everything...")
        isActive.countDown()
      }
    }

    // Doesn't work ;-)
    task.timeout(3.seconds)
  }
}

This variation that uses fiber.start is actually more faithful to the Kotlin version. For my use-case it works as expected. However, the problem with this one is that using fibers via start is unsafe, and maybe it shouldn't be.

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 17+
//KOTLIN 1.7.20
//DEPS org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.runInterruptible
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withContext
import kotlinx.coroutines.withTimeout
import java.util.concurrent.CountDownLatch
import kotlin.time.Duration.Companion.seconds

suspend fun run() =
  coroutineScope {
    val isActive = CountDownLatch(1)
    try {
      // This one is now cancelable (due to `runInterruptible`)
      val task1 = launch {
        runInterruptible(Dispatchers.IO) {
          try {
            isActive.await()
          } catch (e: InterruptedException) {
            println("Cancelling task1...")
            throw e
          }
        }
      }
      val task2 = launch {
        delay(30.seconds)
        isActive.countDown()
      }
      // Note: the ordering of these joins doesn't matter
      task1.join()
      task2.join()
      println("Done!")
    } finally {
      println("Stopping everything...")
      isActive.countDown()
    }
  }

fun main() = runBlocking {
  withTimeout(3.seconds) {
    run()
  }
}

The difference in behavior is that Kotlin sends the cancelation signal to the forked task, whereas Cats-Effect does not. This is what they call "structured concurrency", meaning that forked tasks have to complete before their scope (the main scope or thread) completes as well, and also, when the main scope gets cancelled (or finishes in error), this cancels all children as well.

[djspiewak]

Lots of good stuff in here but just replying quickly…

The reason that Cats Effect doesn't kill child fibers when the parents die is simply because structured concurrency is less general than unstructured. What you're asking for is structured concurrency, just with a more complex structure than the way that we normally think of it (i.e. more complex than something like parMapN). The problem is that sometimes, as a user, you need to be able to create a more arbitrary concurrency graph. start allows you to do this without getting bitten by parent/child relationships, whereas an automatic supervision model does not.

Of course, we could resolve this in the same way ZIO does by having two different primitive starts, but I would argue this muddies the waters more than anything, particularly when one of those starts is more primitive than the other one in that we can derive one from the other given an extra piece of machinery: Resource.

A lot of this comes back to the fact that start is a very low level mechanism and not really intended to show up in userland code very often… similar to Thread#start! Instead, you're almost always better off working with higher-level tools such as Parallel, Fs2, background, etc. This doesn't mean that the primitive ceases to exist or that we try to hide it, but rather it means that the primitive is more powerful than what most users need most of the time, but not more powerful than what the ecosystem as a whole needs some of the time.

[alexandru]

Hi @djspiewak,

I'd argue that if start is low-level, it shouldn't be exposed without warnings, and it definitely shouldn't be used in the very first example of Cats-Effect that people see on the website:

The motivating sample that all newcomers see is unsafe.

Also, Resource doesn't have the semantics I'm after (concurrent jobs should receive the cancellation signal concurrently), and you need to remember to use it. Resource use is explicit, like try-with-resources, and unlike C++'s RAII.

I understand what you mean about using start as a primitive for deriving stuff. Its signature could take a parameter that could specify the scope, with the current behavior being possible by specifying a “global scope” (or global fiber):

task.start(GlobalScope)
// ... or, maybe ...
task.start(FireAndForget)

And it would be a good idea if this wouldn't be the default.

[djspiewak]

it shouldn't be exposed without warnings

It has warnings in the scaladoc. :-)

and it definitely shouldn't be used in the very first example

I'm definitely sympathetic to this viewpoint. I think it would be worth contriving a better example, or a better version of this example. The println stuff is also mildly problematic, though it's nice that it's a very clear example. I basically chose to use start mostly because it allowed me to use for, which I think most people find a little less mysterious than the combinators (and also it colors nicely).

concurrent jobs should receive the cancellation signal concurrently

This is only desirable under certain circumstances though. As Fabio pointed out, this can be used to violate finalizer ordering if applied in general. With that said, making finalizers in Resource more concurrent is definitely something that has been discussed. We do this for the par combinators used on Resource, but not for start or anything derived from it (for various reasons), and doing it for background is generally problematic.

and you need to remember to use it. Resource use is explicit, like try-with-resources, and unlike C++'s RAII.

Yes. This is by design.

So the problem with Resource is it fundamentally changes the way that scopes behave. In doing so, it also introduces a form of unsafety, since Scala's type system is polymorphic and lacks any form of linearity, meaning that it is actually relatively trivial to leak resources in a way that the type system cannot catch (.use(_.pure) being the canonical example). To be clear, this is also possible with IO's resource primitives, but it's a little less of a footgun. Resource causes the associativity of finalizers over flatMap to fundamentally shift, and that's not something we should be doing without at least flagging it in the types.

While this does create some ergonomic issues for fiber initiation, those issues ultimately convert into forcing users to think about what exactly they're trying to do. We don't really need to have this discussion in a vacuum; the warnings on start are a very common question in the Cats Effect Discord channels, as well as within my own work Slack. People generally read the warnings and find their way to background, but if they aren't already within Resource they generally hit a speed bump figuring out how to resolve that type. This speedbump is the point.

Once newcomers hit that speedbump, it opens up a conversation around where their scopes are intended to go, either in the Discord or with more experienced colleagues. Invariably, the result is a more clarified control flow and safer handling of edge cases. All of this would have been bypassed if we simply had a "one size fits all" fiber management policy baked into IO itself.

Ultimately, I do agree that we can do a lot better at providing tools for managing resource scopes, and I think Fabio has talked a few times about how this is probably the next major frontier to explore when it comes to effect system expressiveness, but it's a huge open problem space, one which the language doesn't (presently) help us address, and in any case the answer is definitely not to make it implicit within the existing runtime structures.

Its signature could take a parameter that could specify the scope

This is isomorphic to fork and forkDaemon, and it has the same problem: it makes something primitive (fork) which has a semantic which can be defined in terms of the other.

[SystemFw]

Agreed with @djspiewak answer, but I think we could at least update the docs as a low effort high value initiative, so that start is not front and center. I think we could start from parMapN, and then move to background and Supervisor