Please promote thread pools from experimental to stable

[joshtriplett]

I'd love to use the thread pool mechanism to have an application-wide thread pool sized based on the the number of CPUs, allowing multiple concurrent zstd compression jobs to share that pool rather than each having their own.

The thread pool API is currently in the experimental section. However, the API itself seems very simple: create a pool with a specified number of threads, free a pool, assign a pool to a compression context.

Would it be possible to promote those three functions, and associated opaque type, from experimental to stable?

[Cyan4973]

We could consider it.
In the meantime, if you like the current API, you could use it now, and if you find it useful, report your experience.
Being tagged experimental doesn't mean it doesn't work. It's still fully tested.
But a symbol marked as "stable" is supposed to remain present and exposed "as is" more or less "forever" (or at least up to 2.0, and there is no plan for that), meaning if it's poorly designed or lacks something important it will nonetheless remain like that. So, before reaching that point, we would rather be sure that the API is used, useful, offers a satisfying experience and good value before committing to its "forever" continued maintenance.