Есть ли причина, по которой вы хотели бы указать параметр для max_workers? Почему бы вам не оставить для него значение «Нет» по умолчанию? Всегда ли быстрее иметь меньше рабочих?
Каков вариант использования для ограничения max_workers на concurrent.futures.ThreadPoolExecutor?
comment
Как насчет сценария, в котором вы пытаетесь использовать параллельную обработку, но не хотите связывать все доступные потоки процессора с одной задачей?
- person G. Anderson schedule 27.04.2019
comment
Связано: 1) stackoverflow.com/questions/ 40492894/ 2) stackoverflow.com/questions/47498288/ 3) stackoverflow.com/questions/53385479/ Может быть, кто-нибудь придет и пометит их как обман?
- person sanyassh schedule 27.04.2019
comment
@ Г. Андерсон, конечно, но если скорость является единственным фактором, следует ли вам когда-либо ограничивать количество рабочих?
- person db702 schedule 28.04.2019
comment
Если скорость была действительно единственным фактором, то я не могу придумать причину для ее ограничения. Однако в реальном мире я могу представить несколько случаев, когда это может быть не так, поэтому функциональность должна существовать как опция.
- person G. Anderson schedule 29.04.2019
comment
Возможный дубликат многопоточности Python max_workers
- person G. Anderson schedule 29.04.2019
