About fibers and cancellation

[Angel-O]

Hi 👋, I have 3 questions about fibers and cancellation in cats effect:

1. The Scala docs on .start say that it is an unsafe combinator wrt cancellation. If cancellation is not a concern (for instance if the started fiber does work that is finite, i.e. it won't run forever and perhaps shortlived or if I keep a handle on the fiber making sure to cancel it when needed) is it correct to say that .start is not unsafe ? Or in other words in what situations is it acceptable to call .start ?

2. Besides manually calling .cancel on a fiber and using structured concurrency combinators such as .race, .parMap, etc... and perhaps SIGTERM | SIGINT (or whatever system message is used for graceful shutdown), what else can cause a fiber to be cancelled ? Trying to understand if cancellation is something that can happen unexpectedly.

3. If the purpose of the Supervisor is to tie the lifecycle of a fiber to the supervisor's lifecycle, is it correct to say that if the latter extends to the lifecycle of the entire app (as it's usually the case for Resources in cats effect applications) then there's not much benefit from using it besides perhaps being able to control the termination policy (await = true | false) ? What would help me understand here is a  clear use case where using a supervisor makes a clear difference to the application logic.

Thank you.

[armanbilge]

The Scala docs on .start say that it is an unsafe combinator wrt cancellation. If cancellation is not a concern (for instance if the started fiber does work that is finite, i.e. it won't run forever and perhaps shortlived or if I keep a handle on the fiber making sure to cancel it when needed) is it correct to say that .start is not unsafe

I would still say that start is unsafe . If you keep a handle to the fiber, that doesn't magically make start safe, that just means that you are doing the extra work to manage the fact that it's unsafe :)

if the started fiber does work that is finite, i.e. it won't run forever and perhaps shortlived

Even if the fiber is finite and short-lived, it may acquire resources or have some finalizers. If the application (gracefully) shuts down, those finalizers will not be run.

In general, you should prefer background or Supervisor when possible. However, it is reasonable to use start if you are manually managing the fiber (after all, background and Supervisor are implemented in terms of start :) and in some cases you can make an argument that the unsafety will not be an issue.

---

what else can cause a fiber to be cancelled

A fiber can self cancel via IO.canceled (versus being canceled externally).

Trying to understand if cancellation is something that can happen unexpectedly

Depends what "unexpectedly" means exactly :) no, a fiber will not spontaneously combust cancel. Either something has a handle to the fiber and will cancel it, or it will self-cancel.

and perhaps SIGTERM | SIGINT (or whatever system message is used for graceful shutdown)

Note, the only fiber that is directly canceled by SIGTERM/SIGINT is the main fiber in IOApp#run. Of course, it may propagate cancelation to other fibers via finalizers etc.

---

If the purpose of the Supervisor is to tie the lifecycle of a fiber to the supervisor's lifecycle, is it correct to say that if the latter extends to the lifecycle of the entire app (as it's usually the case for Resources in cats effect applications) then there's not much benefit from using it besides perhaps being able to control the termination policy (await = true | false) ?

No, I would say that's not correct. The benefit is that the finalizers of those fibers (e.g. flushing files, releasing resources, gracefully closing connections) are guaranteed to be called when the app shuts down. If you just use start (instead of a Supervisor) then the fibers will not be finalized when the app shuts down.

[Angel-O]

Hey @armanbilge 👋

Thanks for explaining: it makes sense now :)

[djspiewak]

Adding a more succinct follow-on to @armanbilge's excellent answer…

start is a fundamentally unstructured concurrency primitive. It exists because we (as a scientific field) have not yet found a universal calculus of structured concurrency, and so we didn't want to preclude novel forms of concurrency which are safe but impossible to express in terms of things like race. Fs2 was actually the original example of this, but Supervisor is another good one.

However, inventing novel forms of concurrency is not something most end users need to worry about! Instead of doing this, tools like Supervisor, background, race, par, Fs2, etc should be leveraged. These are all forms of structured concurrency.