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.

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.

Ruby FFI has been experimenting with provided support for kicking external functions to background threads with a single keyword argument.

In a high level dynamic language with exceptions, there's already so many implicit "colors" to a function that I think this is still the right choice.

This "implicit coloring" is what's talked about in _Unyielding_ [1], which is the "explicit color is good" counterpoint to _What Color is Your Function?_ (though Unyielding predates WCIYF by about a year).

[1]: https://glyph.twistedmatrix.com/2014/02/unyielding.html