Multiprocessing i timeout
królewna
tworzenia połączenia miał podawany parametr działający na zasadzie
timeout? Bo obecnie próbując połączyć się z niedziałającym procesem,
proces, który wywołuje funkcje klienta czeka w nieskończoność. Czy będę
musiała przepisać część kodu z biblioteki po swojemu? Bo z tego co widzę
to klasa Client jest tak naprawdę tylko wrapperem, który wywołuje
odpowiednią klasę dla argumentu o odpowiednim rodzaju(mi chodzi o
obiekty typu socket) i nie za bardzo sama ma jakieś inne pola.
Czy może zastosować lepiej jakieś inne rozwiązania do komunikacji między
dwoma programami? Bo różnicy pomiędzy normalnymi socketami z
picklowaniem a multiprocessing.connection nie widzę (jedynie co
zaobserwowałam to to, że przesyłanie przez multiprocessing.connection
jest szybsze) i właściwie do tej pory stosowałam je wymiennie (ze
względu na łatwość wysyłania i odbierania obiektów przez connection).
Czym także różnią się oba sposoby jeśli chcę po prostu wysyłać obiekty
między dwoma obiektami? Czym te dwa sposoby różnią się od BaseManager
przy takiej samej sytuacji?
Bart Ogryczak
> Czy jest jakaś możliwość aby multiprocessing.connection.Client podczas
> tworzenia połączenia miał podawany parametr działający na zasadzie
> timeout?
Może klasycznie uniksowe rozwiązanie:
Łukasz Rekucki
Jak widać nie pomyśleli o tym, ale można użyć
http://docs.python.org/library/socket.html#socket.setdefaulttimeout
tuż przed wywołaniem Client(). Powinno to ustawić timeout na sockecie,
który stworzy SocketClient(). PipeClient() wydaje się mieć ustawiony
na sztywno timeout 1000ms.
królewna
> Jak wida� nie pomy�leli o tym, ale mo�na u�y�
> http://docs.python.org/library/socket.html#socket.setdefaulttimeout
> tu� przed wywo�aniem Client(). Powinno to ustawi� timeout na sockecie,
> kt�ry stworzy SocketClient(). PipeClient() wydaje si� mie� ustawiony
> na sztywno timeout 1000ms.
Przyznam, �e nie rozumiem w jaki spos�b to dzia�a. Tworz� nowy obiekt
klasy socket zupe�nie nie zwi�zany z obiektem klasy Client, zmieniam na
nim timeout i to dzia�a na obiekcie Clienta. Jaka jest zasada dzia�ania
tego? Czyli jak zmieniďż˝ na jednym obiekcie klasy socket np timeout to
ten timeout zmienia siďż˝ na wszystkich?
kr�lewna
Bart Ogryczak
> W dniu 21.12.2009 17:30, Łukasz Rekucki pisze:
>
> > Jak widać nie pomyśleli o tym, ale można użyć
> >http://docs.python.org/library/socket.html#socket.setdefaulttimeout
> > tuż przed wywołaniem Client(). Powinno to ustawić timeout na sockecie,
> > na sztywno timeout 1000ms.
>
> Przyznam, że nie rozumiem w jaki sposób to działa. Tworzę nowy obiekt
> klasy socket zupełnie nie związany z obiektem klasy Client, zmieniam na
> nim timeout i to działa na obiekcie Clienta. Jaka jest zasada działania
> tego? Czyli jak zmienię na jednym obiekcie klasy socket np timeout to
> ten timeout zmienia się na wszystkich?
Nie. Importujesz moduł socket. Zmieniasz domyślny timeout. Wszystkie
sockety utworzone po tej zmianie będą miały taki timeout.
Np.
import socket
socket.setdefaulttimeout(twój_timeout)
...
klient = multiprocessing.connection.Client() # ten klient będzie miał
twój timeout.
królewna
>
> Nie. Importujesz modu� socket. Zmieniasz domy�lny timeout. Wszystkie
> sockety utworzone po tej zmianie b�d� mia�y taki timeout.
> Np.
>
> import socket
> socket.setdefaulttimeout(tw�j_timeout)
> ...
>
> klient = multiprocessing.connection.Client() # ten klient b�dzie mia�
> tw�j timeout.
Oh, przepraszam. By�am prawie pewna, �e w�a�nie zrobi�am tak jak
napisa�am i zadzia�a�o wi�c mnie to zdziwi�o. Ale najwidoczniej
napisa�am tak jak radzi�e� bo teraz sprawdzam i rzeczywi�cie dzia�a tak
jak opisujesz.
William Bonawentura
U�ytkownik "�ukasz Rekucki" <lrek...@gmail.com> napisa� w wiadomo�ci
news:5e45a27a-4515-40c1...@r24g2000yqd.googlegroups.com...
> Jak wida� nie pomy�leli o tym, ale mo�na u�y�
> http://docs.python.org/library/socket.html#socket.setdefaulttimeout
Z zastrze�eniem, �e to jest zmiana globalna - na wszystkie w�tki.
Daniel Mróz
>> Jak widać nie pomyśleli o tym, ale można użyć
>> http://docs.python.org/library/socket.html#socket.setdefaulttimeout
Dlatego najlepiej timeouty implementować na select.select lub select.*Poll,
np. (piszę z pamięci, więc może nie działać, ale ogólną zasadę Królewna
wyczai):
sock = socket.socket(<co tam potrzeba>)
sock.setblocking(0)
poller = select.poll()
poller.register(sock.fileno(), select.POLLOUT)
try:
sock.connect(<co tam potrzeba>)
except socket.error, e:
if e.args[0] not in (errno.EINPROGRESS, errno.EALREADY, errno.EWOULDBLOCK):
sock.close()
raise
else:
pass
except:
sock.close()
raise
events = poller.poll(<wybrany timeout>)
if not events:
sock.close()
raise JakiśTamWyjątek('Connect timeout')
sock.setblocking(1)
W Pythonie 3.0 już są AFAIR timeouty per obiekt gniazda, a nie
globalne, ale nie pamiętam czy obejmowały one przekroczenia czasu
połączenia, czy tylko timout transferu danych.
Pozdrawiam
Beorn
--
Daniel 'Beorn' Mróz <be...@alpha.pl> http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*]
[ r++ y+ ]
William Bonawentura
Użytkownik "Daniel Mróz" <be...@alpha.pl> napisał w wiadomości
news:slrnhjchh0...@pino.cyberdeck.pl...
>
>
> W Pythonie 3.0 już są AFAIR timeouty per obiekt gniazda, a nie
> globalne, ale nie pamiętam czy obejmowały one przekroczenia czasu
Są i w 2.6
Łukasz Rekucki
> Użytkownik "Daniel Mróz" <be...@alpha.pl> napisał w wiadomościnews:slrnhjchh0...@pino.cyberdeck.pl...
>
>
>
> > W Pythonie 3.0 już są AFAIR timeouty per obiekt gniazda, a nie
> > globalne, ale nie pamiętam czy obejmowały one przekroczenia czasu
>
> Są i w 2.6
W każdej wersji gdzie jest setsockopt()! Ale w ogóle nie o to tu
chodziło. Problem był taki, że konstruktor klasy
http://docs.python.org/library/multiprocessing.html#multiprocessing.connection.Client
, który wewnętrznie tworzy sobie socket do którego nie masz dostępu,
nie przyjmuję takiej opcji.
>> Jak widać nie pomyśleli o tym, ale można użyć
>> http://docs.python.org/library/socket.html#socket.setdefaulttimeout
> Z zastrzeżeniem, że to jest zmiana globalna - na wszystkie wątki.
W kontekście multiprocessing, jakoś bym się tym nie martwił ;), ale
tak - należy o tym pamiętać