...
Support for debugging Fibers has been partially implemented. Fibers will appear to the debugger as ordinary threads. When you view the list of threads from within the debugger, you will see both fibers and the carrier threads they run on. Depending on the debugging mode, not all fibers may appear in the thread list. See Fiber Debugging Modes below.
If a fiber is mounted, both the fiber and its carrier thread are basically the same execution context. If one is at a breakpoint, they both will appear to be at the same breakpoint. They will have the same stack traces, and single stepping in one advances the PC in the other. They are essentially two different views of the same thread (with some minor exceptions in debugger behavior noted below).
...
- Suspending or resuming a specific fiber. When the debugger asks for all threads to be suspended (which is usually what happens at breakpoints), the fibers will also be considered suspended. However, do not try to suspend a specific fiber, or resume any fiber that was suspended as a result of suspending all threads.
- Setting local variables in fibers (you can view them). This actually applies to fiber frames, even if the current thread is a carrier thread. More specifically, you cannot set locals in continuation frames.
- Dealing with a large number of fibers. For one, you will overwhelm the debugger because it will see them all. Also, fibers are not tracked in an efficient manner by the debug agent, so it can also become bogged down.
- Forcing a fiber frame to return ("Drop Frame" in Intellij), although this should work fine if executed from the carrier thread context instead of the fiber context.
...
Fiber Debugging Modes
There are plans to be able to pass a flag to the debug agent to control how it supports fibers. Likely options are:
By default the debugger is only notified of fibers for which certain events have arrived on (breakpoint, exception, and watchpoint being the most notable). This is necessary when debugging a vary large number of fibers, because you wouldn't want every single fiber to appear as a thread in the debugger. This behavior can be overridden with the "fibers" option passed on the command line to the debug agent.
fibers=all
fiberdebug=on
: The debugger will see all fibers (this is what is currently implemented).fibers. Use only when you have a manageable number of fibers, and you don't mind all of them appearing in the debugger's thread list.fibers=n
fiberdebug=off
: The debugger will not see any fibers. This will be useful Use this option when using a large number of fibers and not needing any fiber specific debugging support (like single stepping through a fiber as it switches carrier threads).fiberdebugfibers=partialy
: This is the default. The debugger will only see interesting fibers for which certain events have arrived on. This will be useful when using a large number of fibers, and only needing to debug some fibers. The fibers that will be visible will be the ones that some sort of event has happened on, such as a breakpoint. This would, for example, allow you to single step in a fiber that you hit a breakpoint in, but not require that the debugger know about every fiberdebugger will become aware of a fiber when certain events arrive on it, such a breakpoint, watchpoint, or exception. Once one of these events arrives, you can then single step through the fiber code, even as it switches carrier threads.
Miscellaneous Implementation Details
...