I’m not too happy with the wording here — “process requests” is pretty ambiguous. That said, I can’t think of a better term.

I think it's good. I came up with "responding to requests", but is that calling the database, or is that just serializing a response body? My term is worse.

Request processing logic is specified by the HttpApp

On re-reading, I don't think this is correct. The handlers specified by HttpApp[IO] would run on the Async[F].executionContext pool instead, wouldn't they. It would just be Futures defined internally to blaze that would run on this custom execution context.

It might be simpler to say that this is a compute pool for running async computations and leave it at that, without going into detail on what exactly is run.

I understood this deeply a few effect systems ago, but had to do some experiments now! Using withExecutionContext(scala.concurrent.ExecutionContext.global), with this route:

      case GET -> Root / "thread" =>
        F.delay(Thread.currentThread.getName).flatMap(Ok(_))

• The response body is io-compute-#. I'd say this is the "logic specified by the HttpApp".
• reqLoopCallback gets called on blaze-selector-#
• runRequest gets called on io-compute-#
• renderResponse gets called on io-compute-#.
• The effect of writing the body with bodyEncoder gets called on io-compute-#. req loop callback gets called again on the same thread.

So what actually does happen on the ExecutionContext?

• The runnable after we have parsed a request, but we were already on a compute pool.
• Some scheduled tasks, like the idle timeout
• Probably some onComplete handlers in blaze that I can't trace from this repo
• Every EntityBodyWriter has one, but I compiled without it!

It's a lot less useful than it used to be! I think the less-detailed description is better for now, and we might be able to rip out more places it's used with the advances in CE3.