Używam multiprocessing.dummy.Pool
. Tworzę pojedynczą pulę wątków na poziomie modułu, a następnie używam pool.apply_async(requests.get, [params])
do uruchomienia zadania.
To polecenie daje mi przyszłość, którą mogę dodawać do listy z innymi przyszłymi kontraktami w nieskończoność, dopóki nie będę chciał zebrać wszystkich lub niektórych wyników.
multiprocessing.dummy.Pool
jest, wbrew wszelkim logikom i powodom, pulą THREAD, a nie puli procesów.
Przykład (działa zarówno w Pythonie 2 i 3, o ile jest zainstalowany wnioski):
from multiprocessing.dummy import Pool
import requests
pool = Pool(10) # Creates a pool with ten threads; more threads = more concurrency.
# "pool" is a module attribute; you can be sure there will only
# be one of them in your application
# as modules are cached after initialization.
if __name__ == '__main__':
futures = []
for x in range(10):
futures.append(pool.apply_async(requests.get, ['http://example.com/']))
# futures is now a list of 10 futures.
for future in futures:
print(future.get()) # For each future, wait until the request is
# finished and then print the response object.
Wnioski będą realizowane równocześnie, tak działa cały dziesięć z tych wniosków nie powinno trwać dłużej niż najdłuższy jeden. Ta strategia będzie używać tylko jednego rdzenia procesora, ale nie powinno to stanowić problemu, ponieważ prawie cały czas będzie spędzać czas oczekiwania na wejścia/wyjścia.
przeciwieństwie do kwestii współbieżności CPU-bound w Pythonie, to mogłaby być rozwiązana w osobnym wątku, albo użycie 'multiprocessing.dummy' dla puli wątków . –