On Sun, Nov 17, 2024 at 08:19:59PM +0100, Maciej S. Szmigiero wrote: > From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com> > > Migration code wants to manage device data sending threads in one place. > > QEMU has an existing thread pool implementation, however it is limited > to queuing AIO operations only and essentially has a 1:1 mapping between > the current AioContext and the AIO ThreadPool in use. > > Implement generic (non-AIO) ThreadPool by essentially wrapping Glib's > GThreadPool. > > This brings a few new operations on a pool: > * thread_pool_wait() operation waits until all the submitted work requests > have finished. > > * thread_pool_set_max_threads() explicitly sets the maximum thread count > in the pool. > > * thread_pool_adjust_max_threads_to_work() adjusts the maximum thread count > in the pool to equal the number of still waiting in queue or unfinished work. > > Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
All the comments so far make sense to me too, so if you address all of them, feel free to take this alone: Reviewed-by: Peter Xu <pet...@redhat.com> -- Peter Xu
