If a mutex is unlocked outside of a task and all the workers have started to sleep, the unlock will not wake the workers, causing an infinite sleep until new work is enqueue. A condition variable may be required to solve this, used in the fallthrough case where a worker is about to sleep.

Unfortunately, Boost.Context fibers are only able to be used once before being invalidated, so the existing scheme of jumping to arbitrary fibers from the pool will no longer work, at least not without some modifications. One potential solution is to, when resuming from a jump within a fiber, look at the previous fiber index, and if it's valid then update its context pointer to be the current fiber's parent context.

The build scripts for third party dependencies should be moved outside of their respective directories, and instead placed in the base ThirdParty/ directory. This allows less intrusion on the third party library, keeping it in a vanilla state. In addition, rename the third party build scripts to have the names of the library they build. See the xenia project for a demonstration of this practice.

If a job is suspended on one worker thread, then resumed on another it will disconnect the Tracy profiler with a multiply-ended zone dialogue error. This is due to a lack of support for usermode threading in the profiler, see wolfpld/tracy#106 for tracking support.

Unfortunately, the POSIX functions getcontext, makecontext, and swapcontext are deprecated and should not be used. These functions are currently used in the Linux implementation, which needs to be changed. Instead, assembly must be used for the Linux implementation.

If a fiber is pulled from the available pool from within a running fiber, such as during a wait enqueue, and that new fiber happens to need to deal with the shutdown sequence, the parent context is not the worker fiber, but is instead the fiber that scheduled it. This causes a high chance of a crash if a job has a dependency.

The first time a fiber is scheduled, the transfer data is written based on the previous fiber's jump. If we leave this fiber and resume it later, the transfer payload won't be updated, and still refer to the original fiber. This causes a serious issue where we fix up the wrong fiber when repairing the previous fiber during a schedule. To fix this, we might need to modify the assembly of Boost.Context to not use a transfer payload, and to not invalidate a fiber after jumping to it.