Czy concurrent.futures jest lekiem z GIL?

Właśnie szukałem tej nowej implementacji i używam Pythona 2.7, muszę zainstalować this, więc jeśli z niego skorzystam, zapomnę słowa GIL na CPython?Czy concurrent.futures jest lekiem z GIL?

Źródło

2013-02-20 Abdelouahab Pp

http://www.dalkescientific.com/writings/diary/archive/2012/01/19/concurrent.futures.html –

http://docs.python.org/dev/library/concurrent.futures.html # module-concurrent.futures - nie wspomina nic o GIL, więc wątki, które używa, są najwyraźniej prawdziwymi wątkami. W przeciwnym razie, po co zawracać sobie głowę tym całym hulabaloo? –

Odkryłem, że asynchroniczny kod uwielbia używać concurrent.futures, więc powiedziałem, że był to lek dla GIL –

Nie, concurrent.futures nie ma prawie nic wspólnego z GIL.

Używanie procesów zamiast gwintów jest lekiem dla GIL. (Oczywiście, jak każdy lek, ma skutki uboczne. Ale to działa).

Moduł futures tylko daje prostszy sposób, aby zaplanować i czekać na zadania niż przy użyciu threading lub multiprocessing bezpośrednio. Dodatkową zaletą jest to, że można zamienić między pulę wątków i pulę procesów (a może nawet pętlę greenletową lub coś szalonego, co wymyślasz i budujesz) bez zmiany kodu future. Tak więc, jeśli nie wiesz, czy twój kod będzie miał problemy z GIL, możesz go zbudować, aby używać wątków, a następnie przełączyć go do używania procesów z jednokrotną zmianą, co jest całkiem miłe.

Ale jeśli użyjesz ThreadPoolExecutor, będzie on miał dokładnie takie same błędy GIL, jak gdyby twoja pula wątków, kolejka zadań itp. Ręcznie z threading i queue. Jeśli użyjesz ProcessPoolExecutor, unikniesz problemów z GIL w ten sam sposób (iz tymi samymi kompromisami), jak gdyby używałeś ręcznie multiprocessing.

A pakiet PyPI to zwykły backport modułu concurrent.futures od 3.2 do 2.x (i 3.0-3.1). (To nie magicznie daje nową i-sort-of-ulepszony 3,2 Gil, lub bardziej ulepszoną 3,3 Gil, znacznie mniej usunąć GIL.)

pewnie nawet nie powinno mieć wspomniałem o zmianach GIL, ponieważ wydaje się, że to tylko spowodowało zamieszanie ... ale teraz, pozwólcie, że spróbuję to wyprostować, nadmiernie upraszczając.

Jeśli nie masz nic oprócz pracy związanej z IO, wątki są świetnym sposobem na uzyskanie współbieżności, do rozsądnego limitu. A 3.3 sprawia, że działają jeszcze lepiej - ale w większości przypadków 2,7 jest już wystarczająco dobry i, w większości przypadków, gdzie nie jest, 3.3 wciąż nie jest wystarczająco dobry. Jeśli chcesz obsłużyć 10000 równoczesnych klientów, zamiast używać wątków, będziesz chciał użyć pętli zdarzeń (np. twisted, tornado, gevent, tulip itd.).

Jeśli masz pracę związaną z procesorem, wątki nie pomagają w ogóle w tej pracy. W rzeczywistości pogarszają sytuację. 3.3 sprawia, że kara nie jest tak zła, ale wciąż jest karą, a ty wciąż nie powinieneś tego robić. Jeśli chcesz zrównoważyć pracę procesora, musisz użyć procesów, a nie wątków. Jedyną zaletą 3.3 jest to, że futures jest nieco łatwiejszy w użyciu niż multiprocessing i jest wbudowany zamiast konieczności instalacji.

Nie chcę zniechęcać cię do przejścia do wersji 3.3, ponieważ jest to lepsza implementacja lepszego języka niż 2.7. Lepsza współbieżność nie jest jednak powodem do przeprowadzki.

Źródło

2013-02-20 23:18:01 abarnert

więc są to różne rzeczy! to było, że GIL został napisany ponownie na 3.2, że wydaje mi się, że jest współbieżny. Rozwiązania, które rozwiązują problem, dziękuję :) –

@AbdelouahabPp: Nie, 'concurrent.futures' nie _nie_ rozwiązuje żadnego problemu, z wyjątkiem problemu tworzenia współbieżny kod nieco prostszy do napisania. Zmiany w GIL w 3.2 i 3.3 są całkowicie niezależne i to tylko zbieg okoliczności, że pierwsza znacząca zmiana GIL w ciągu dekady pojawiła się w tej samej wersji Pythona, co biblioteka 'futures'. – abarnert

, więc powinienem przejść do wersji 3.3, jeśli chcę uzyskać doskonały współbieżny kod! dziękuję :) i przepraszam, ponieważ ten wątek wrócę do niego kilka razy, aby uzyskać więcej pomysłu, jestem początkujący, i znalazłem tę bibliotekę z Tornado –

Czy concurrent.futures jest lekiem z GIL?

Odpowiedz

Powiązane problemy