Add IORuntime#liveFiberSnapshot

[armanbilge]

Starting from the obvious 😂

Fixes #2580. Fixes #3025.

[armanbilge]

Maybe we should expose a method that returns a String (collection)? Something that can be called from the IDE/debugger easily.

[armanbilge]

Actually I'm not sure how useful that is. I guess a test framework would call this method during its timeout hook on a test.

[armanbilge]

If we don't want to expose this here, we could make it a method in the testkit package. Then only test frameworks could use it.

[djspiewak]

So I think that rolling it up in this way is probably unhelpful. I think what we want is something isomorphic to this:

final class IORuntime(...) { 
  // ...

  /**
   * We should have a warning here about memory leaks, since it contains hard references to Fiber(s)
   */
  def snapshot(): List[FiberInfo] = ???
  def metrics(): IORuntimeMetrics = ???
}

final case class IORuntimeMetrics(enqueued: Int, foreign: Int, waiting: Int, workers: List[IORuntimeWorkerMetrics])
final case class IORuntimeWorkerMetrics(index: Int, enqueued: Int)

final case class FiberInfo(fiber: Fiber[IO, _], state: FiberState, trace: FiberTrace)

sealed class FiberState(override val toString: String) extends Product with Serializable

object FiberState {
  case object Running extends FiberState("RUNNING")
  case object Blocked extends FiberState("BLOCKED")
  case object Yielding extends FiberState("YIELDING")
  case object Waiting extends FiberState("WAITING")
  case object Active extends FiberState("ACTIVE")
}

final case class FiberTrace(frames: List[StackTraceElement]) {
  def pretty: String = ???
}

We should gather the FiberInfos into a List at the last possible moment, keeping everything lazy up to that point. In this way, we can refactor liveFiberSnapshot itself to work in terms of these data structures without loss of generality or memory safety.

I believe the above should be sufficient for any external framework to implement the type of semantic they want. It's still an open question of what form that integration should take, but it's more of a problem for munit/specs/etc.

[Daenyth]

What work remains on this? Is there a clear spot where someone can come in and help?

[armanbilge]

@Daenyth

What work remains on this?

I think I've copied Daniel's proposed data structures into the PR. If I haven't yet, that's the first step.

Then, all existing fiber dump machinery should be migrated to those data structures. Currently it is just string manipulation.

Is there a clear spot where someone can come in and help?

Yep, someone can take over the PR (or start from scratch) proceeding with the above. I would appreciate it!!