Faster startup by offloading glob matcher building to a worker thread

[cyqsimon]

This is a much simpler and unsurprisingly better try than #2836.

Instead of an expensive thread pool, we simply create one simple worker thread to blindly build every builtin glob matcher until completion (or made to stop). Doing this early results in effective parallelization and therefore saves time. This may end up doing more work than strictly necessary, but that's not what we care about.

[cyqsimon]

Using the same benchmark procedure as #2836 (comment), I got the following results:

indeterminant.json

I would consider this a success.

[sharkdp]

I've had problems in the past with threads that are never joined. Are we sure this can not cause any problems?

[cyqsimon]

I gave this some thought, but in the end couldn't see any possible failure mode. The thread is so simple that it's trivial to reason about its exact behaviour.

I believe it's okay to forgo joining the thread because there's no resource the thread holds that needs to be released upon halting - BUILTIN_MAPPINGS is 'static, and the halt flag is safely behind an Arc. The only synchronization requirement is to make sure that it indeed does halt, which it obviously does.

If you prefer defensive coding just to be safe, I can do that too. But in this case I really don't think it's necessary.

[sharkdp]

We recently had a problem in another project of mine where a non-joined thread caused problems on Windows (sharkdp/numbat#298). But that might have been only due to the fact that the background thread was accessing the network(?).

[sharkdp]

Anyway, I guess I'm okay with giving this a shot 😄. But those type of things can be hard to track down (spurious crashes that depend on precise timings).

[cyqsimon]

We recently had a problem in another project of mine where a non-joined thread caused problems on Windows (sharkdp/numbat#298). But that might have been only due to the fact that the background thread was accessing the network(?).

Yeah in that case releasing the socket (a shared resource) would require synchronization. We don't have that problem here.

Anyway, I guess I'm okay with giving this a shot 😄. But those type of things can be hard to track down (spurious crashes that depend on precise timings).

I guess I'll add a comment in the threading code to remind future maintainers to watch out for synchronization issues if it ever starts to hold interesting resources in the future.

[cyqsimon]

Also, that's a really interesting project you've got there! When I've got time I would like to take a look at the possibility of integrating it with Krunner.

[sharkdp]

Great idea. Let me know how if you have problems with the current API. It's not really stable and/or particularly nice at the moment, but I have built several frontends for Numbat so far. And there is a 3rd party integration into a krunner-like launcher here: https://github.com/MatthiasGrandl/Loungy/blob/main/src/commands/root/numbat.rs

[sharkdp]

Thank you!