From guillaume.quintard at gmail.com Wed Aug 13 05:32:02 2025 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Tue, 12 Aug 2025 22:32:02 -0700 Subject: Threads and thread polls thought for 8.0 Message-ID: Hi all, There's a thing that has been bugging me for years, and maybe it's time to change/break it with 8.0. The fact that thread_pool_min/max is per pool is generally pretty confusing to users. Could we consider retiring them and have simpler thread_min/max parameters that would be split evenly across pools? It's a bit more code, but it would save me a few discussions when teaching/supporting new users :-) -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Aug 18 13:59:00 2025 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Aug 2025 13:59:00 +0000 Subject: Threads and thread polls thought for 8.0 In-Reply-To: References: Message-ID: <202508181359.57IDx0B0083815@critter.freebsd.dk> -------- Guillaume Quintard writes: > There's a thing that has been bugging me for years, and maybe it's time to > change/break it with 8.0. > > The fact that thread_pool_min/max is per pool is generally pretty confusing > to users. Could we consider retiring them and have simpler thread_min/max > parameters that would be split evenly across pools? > > It's a bit more code, but it would save me a few discussions when > teaching/supporting new users :-) We talked about this at bugwash today: No objection (but Nils on vacation) Probably keep old params around undocumented, and just multiply by #pools and set the new param. Also: Was changing #pools on the fly ever useful for anybody or should we GC tha feature and simplify the code ? Care to open a ticket, preferably with a patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.