"cedeMap" and "intercede" combinators

[armanbilge]

Explicitly cede-ing between expensive compute-bound operations is one of the strategies for addressing CPU-starvation and is suggested in the warning.

cats-effect/core/shared/src/main/scala/cats/effect/CpuStarvationCheck.scala

Lines 43 to 44 in 832079a

	"""[WARNING] Your CPU is probably starving. Consider increasing the granularity
	|of your delays or adding more cedes. This may also be a sign that you are

How to do this is described in the scaladocs for cede.

cats-effect/kernel/shared/src/main/scala/cats/effect/kernel/GenSpawn.scala

Lines 263 to 269 in 52b5a3b

	* The danger is that these types of long-running actions outside of the monadic context can
	* result in degraded fairness properties. The solution is to add an explicit `cede` both
	* before and after the expensive operation:
	*
	* {{{
	* (fa <* F.cede).map(data => expensiveWork(data)).guarantee(F.cede)
	* }}}

Implementing that correctly is not completely trivial (*cough* #3166 😜) and noisy enough that it probably deserves its own combinator.

In fact I think we need a couple combinators, depending on whether or not the expensiveWork() is in F[_] or not.

def cedeMap[A, B](fa: F[A])(f: A => B): F[B] =
  (fa <* cede).map(a => f(a)).guarantee(cede)

def intercede[A](fa: F[A]): F[A] =
  cede *> fa.guarantee(cede) 

(Names subject to bikeshed.) These should also be added as syntax and on IO itself.

I think both variants are important, because for example the following would not achieve the desired semantics.

fa.flatMap(data => intercede(F.pure(expensiveWork(data))))

There, expensiveWork() would be computed eagerly when the pure(...) is constructed (before the cede), not when it is interpreted (after the cede).

[biuld]

I want to help resolve this issue. 😃

[armanbilge]

@biuld go for it!