Closed cmyr closed 2 months ago
it's not threadpool size, it's the fact that by design rayon uses a process-global threadpool... since fontc
's runloop blocks the running thread, running fontc
in parallel (in-process) on the global runloop always risks deadlock if fontc
is trying to submit work to that same threadpool, as long as the number of fontc
runs is >= to threadpool size; so I think that this change is just good practice, I don't think we should be running work on the global threadpool that is is deadlock prone in this way.
I ran into an issue where both fontc and fontc_crater (using fontc as a dependency) were using the implicit global threadpool, and this led to a deadlock where a new compilation operation was started on each available thread, which meant there were no threads available for the actual work to be done.
Using an explicit threadpool in fontc ensures this can't happen in the future.