To be honest the really simple change of allowing pathing in the 'background' to the main DF thread would improve performance significantly for the majority of players without being a major amount of work. I'd suggest do that first then improve later. (following the "there is always time to improve later" mantra)
My doubts about this are related to the fact that when I run DF, it's machine speed rather than framerate capping that limits the timely progression. Maybe if the routing could be optimised to the extent that it doesn't freeze the world when immigrants or invaders are about to enter the world (for example... I've always assumed that the mass path-calculation is what's caused the freeze,
just before the relevent notification comes up) then maybe I would have free cycles to spare to do some speculative "just in case" path searching as opposed to the "just in time" that takes exactly as long as it needs to, anyway, because the world can't help but wait[1].
But unless you have got that luxury, adding the overhead of a management process for multithreading[2]
and adding in the pursuit of speculative not-necessarily-usable calculations (rather than the not-
eventually-usable calculations already inherant in nature of path searching, and which caching/etc should help to avoid or keep to avoid later unnecessary redoing) seems to me to be a less than optimal approach, overall.
But that's an impression, only. I'm probably misrepresenting the process.
[1] The exception to this general rule is the occasional notification of things that should only be happening while the world is running (e.g. strange moods and births) that interupt the world-frozen resource management phases. Of course, these are rare enough events that it's hard to replicate and properly analyse. I've always assumed that there's already a multithreading queue for some things, that initiated an enquiry
just before changing to the management mode and continue for a second or two in the background to give the new baby its character, etc, and then announcing the arrival. But then I'm not too familiar with Toady's code.
[2] Noting my comment in the above footnote that there may already be one in place... Could that be used for minimal extra overheading?