Closed belluzj closed 2 months ago
I think (at least while we don't have a better solution) this should happen only when threading is enabled (such as when --auto-jobs
is used).
I added that but only as a way for you and Simon to see if you like the sound of it, you'll probably find better places to put that information
thanks
Description
This is a draft to propose an idea to fix #4638
I'm eager-loading all tables of the ttFont under test while we're opening the ttFont in a cached_property, because that decorator uses proper locking. In my previously failing test with
--auto-jobs
, this now completes the run without errors, however it introduces a long pause at the start of execution before running any test, presumably while the whole font gets loaded.An alternative solution would be to introduce locking in fontTools, so that lazy-loading a single table has a lock on that entry in the TTFont table cache. That way, only the tables actually needed by tests would get loaded.
It could be interesting to try also with deepcopy; and yet another idea could be that the getter would need to be cached per-thread instead of globally, i.e. use thread-local storage for the caching of cached_property, and so have one ttFont instance per thread. There would be duplicated work to load tables but each thread would have its own copy so hopefully they wouldn't step on each other's toes, and possibly each thread would only load the few tables that the checks running in that thread will use.
Checklist
CHANGELOG.md