Improve Fiber::ExecutionContext.default_workers_count
#16149
Conversation
This I feel would be a mistake. While from a pure processing point of view it would probably be ok, there are other situations where you do outgoing calls in some way that may block execution but might not be very costly from a CPU perspective. The classical example would be a thread pool having a bunch of threads reading from spinning disks in parallel - then it may make sense to overcommit by a lot. I suppose the usefulness of that particular example goes down when using io_uring as the event loop, but there are other situations where it may make sense. EDIT: Oh, this caps only the DEFAULT value? Ok, that make a lot of sense. Never mind then |
|
It's not even the actual default parallelism, it's the one we recommend when you opt in to MT by resizing the default context. |
- Makes sure there is at least 1 worker (minimum required). - Doesn't cap the total to an arbitrary number. - Caps the total to the effective logical CPUs when supported (linux).
ysbaddaden
force-pushed
the
fix/ec-dont-cap-default-workers-count
branch
from
70ddc98 to
f619d2f
Compare
Depends on #16148.