Problem
Config's defaults size every table for a server-shaped workload. A caller that only ever makes one request at a time on one socket has to know that and hand-trim fields like max_handles and max_operations itself — there's no documented "this is safe to shrink to" guidance and no preset for the shape.
Why it matters
Perry's P11 lane (perry-http-client, used by the perry CLI and by perry-ext-axios's blocking-pool requests) is exactly that caller: it builds one turnloop::Loop, turns it to completion, and drops it, for a single outbound connection. It trims max_handles to 8 and max_operations to 32 by hand, with no way to know those numbers are actually safe — every such caller has to make the same guess independently.
(Separately, turnloop#75 makes an oversized max_handles cheap when idle by paging the handle table, which reduces the cost of not trimming — but a caller building a genuinely single-purpose loop still has no documented floor or preset to reach for instead of guessing values by hand.)
What would fix it
A Config::single_connection() constructor (or equivalent named preset), or documented guidance on the floor values that are safe to trim to for a one-socket, one-request-at-a-time caller — so a caller building a short-lived, single-purpose loop doesn't have to guess.
Problem
Config's defaults size every table for a server-shaped workload. A caller that only ever makes one request at a time on one socket has to know that and hand-trim fields likemax_handlesandmax_operationsitself — there's no documented "this is safe to shrink to" guidance and no preset for the shape.Why it matters
Perry's P11 lane (
perry-http-client, used by theperryCLI and byperry-ext-axios's blocking-pool requests) is exactly that caller: it builds oneturnloop::Loop, turns it to completion, and drops it, for a single outbound connection. It trimsmax_handlesto 8 andmax_operationsto 32 by hand, with no way to know those numbers are actually safe — every such caller has to make the same guess independently.(Separately, turnloop#75 makes an oversized
max_handlescheap when idle by paging the handle table, which reduces the cost of not trimming — but a caller building a genuinely single-purpose loop still has no documented floor or preset to reach for instead of guessing values by hand.)What would fix it
A
Config::single_connection()constructor (or equivalent named preset), or documented guidance on the floor values that are safe to trim to for a one-socket, one-request-at-a-time caller — so a caller building a short-lived, single-purpose loop doesn't have to guess.