Re:Ruby 3.0 and the new FiberScheduler interface
by rdw on Tuesday December 29, 2020 @04:13PM
(#25575101)
This is gonna sound pedantic but I think it's not a coloring problem. Coloring is when syntactically a function has to change its own signature just because it started calling an inner function with the new color.
That said, you're right in that one may have to make some changes to code to get around some new problems. The problem with FFI/CPU-heavy functions is that they prevent _other_ fibers from being scheduled while they run.
If it becomes possible to implement work-stealing, then that would mitigate the problem. It would also be solvable by sprinkling "yield to scheduler" calls throughout such functions. Annoying and not always possible, but, since in these cases the signature would not change, technically not coloring.
Re:Ruby 3.0 and the new FiberScheduler interface
by gpderetta on Tuesday December 29, 2020 @05:08PM
(#25575646)
It is not pedantic at all, you are completely right; if this implementation were to be classified as coloroing, then everything would be, including classic threads.
That said, you're right in that one may have to make some changes to code to get around some new problems. The problem with FFI/CPU-heavy functions is that they prevent _other_ fibers from being scheduled while they run.
If it becomes possible to implement work-stealing, then that would mitigate the problem. It would also be solvable by sprinkling "yield to scheduler" calls throughout such functions. Annoying and not always possible, but, since in these cases the signature would not change, technically not coloring.