🚀 go-pugleaf

On Jan 26, 3:54 pm, królewna <krole...@ee.pl> wrote:
> Witam,
>
> Czy jest jakiś sposób, aby wątek mógł odnieść się do samego siebie (tak
> jak w klasie jest self). Chodzi o wątek utworzony przez
> threading.Thread. Chcę po prostu aby wątek ściągał siebie samego z
> listy. Niestety bez dostępu do siebie nie mogę tego zrobić.

Chodzi o to?
http://docs.python.org/library/threading.html#threading.currentThread

On 26.01.2010, królewna <krolewna@ee.pl> wrote:
> Czy jest jakiś sposób, aby wątek mógł odnieść się do samego siebie (tak 
> jak w klasie jest self). Chodzi o wątek utworzony przez 
> threading.Thread. Chcę po prostu aby wątek ściągał siebie samego z 
> listy. Niestety bez dostępu do siebie nie mogę tego zrobić.
>
> Czy jedynym obejściem jest tworzenie klasy dziedziczącej po 
> threading.Thread i użycie self czy jednak wątek może się odwołać do 
> samego siebie?
Chwilunia. Czy Ty masz gdzieś listę wątków i chcesz aby wątki te same
siebie z niej usuwały w przypadku zakończenia pracy?
Jeśli tak, to tym powinien się zajmować zarządca wątków, np. główny wątek,
który okresowo sprawdza przez isAlive() i sam czyści listę (lub na
nowo odpala wątek jeśli zmarł, a powinien chodzić).
"Gubienie" referencji do wątków to bardzo zły pomysł.

Co do samego problemu, zamiast trzymać listę wątków, zapamiętuj je w
słowniku, którego kluczami będą ich nazwy (które sobie jakoś możesz
generować). Kiedy wątek będzie chciał się z tego słownika usunąć,
niech wywoła metodę zarządcy wątków (np. wątku głównego, do którego
referencję możesz przekazać w kontruktorze threading.Thread), która
dokona odpowiedniego czyszczenia. Tylko pamiętaj o lockach!


Pozdrawiam
Beorn

-- 
Daniel 'Beorn' Mróz <beorn@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+                           ]

On 26 Sty, 15:54, królewna <krole...@ee.pl> wrote:
> Witam,
>
> Czy jest jakiś sposób, aby wątek mógł odnieść się do samego siebie (tak
> jak w klasie jest self). Chodzi o wątek utworzony przez
> threading.Thread. Chcę po prostu aby wątek ściągał siebie samego z
> listy. Niestety bez dostępu do siebie nie mogę tego zrobić.
>
> Czy jedynym obejściem jest tworzenie klasy dziedziczącej po
> threading.Thread i użycie self czy jednak wątek może się odwołać do
> samego siebie?
>
> --
> krolewna

Dziedziczenie z threading.Thread jest przecież bardzo łatwe i
przyjemne. Wystarczy tyle: http://wklej.org/id/269175/ i w funkcji run
() piszesz kod. Jeśli trzeba przekazać jakieś parametry - też nie ma
sprawy, wystarczy dodać konstruktor: http://wklej.org/id/269174/

Wątkiem zwykle zarządza wątek nadrzędny (master/worker pattern, thread
pool pattern)

Użytkownik "Daniel Mróz" <beorn@alpha.pl> napisał w wiadomości 
news:slrnhlu4tp.94n.beorn@pino.cyberdeck.pl...
> Co do samego problemu, zamiast trzymać listę wątków, zapamiętuj je w
> słowniku, którego kluczami będą ich nazwy (które sobie jakoś możesz
> generować).

Każdy wątek otrzymuje unikalną nazwę z automatu. 

On 27.01.2010, William Bonawentura <news@ipartners.pl> wrote:
>> Co do samego problemu, zamiast trzymać listę wątków, zapamiętuj je w
>> słowniku, którego kluczami będą ich nazwy (które sobie jakoś możesz
>> generować).
> Każdy wątek otrzymuje unikalną nazwę z automatu. 
Owszem, dlatego napisałem "możesz". Osobiście preferuję nadawanie nazw
samemu, dzięki czemu można w wątku zrobić np. logging.getLogger(self.getName())
czy inne zabawy.


Pozdrawiam
Beorn

-- 
Daniel 'Beorn' Mróz <beorn@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+                           ]

Dziękuje wszystkim. Bardzo się przydały Wasze podpowiedzi (szczególnie 
Twoja uwaga Bart). Aż mi znowu wstyd, że piszę na tę grupę.

--
królewna

On Jan 27, 11:51 am, królewna <krole...@ee.pl> wrote:
> Dziękuje wszystkim. Bardzo się przydały Wasze podpowiedzi (szczególnie
> Twoja uwaga Bart). Aż mi znowu wstyd, że piszę na tę grupę.

NP, przynajmniej jakiś ruch jest ;-)

W dniu 27.01.2010 11:51, królewna pisze:
> Dziękuje wszystkim. Bardzo się przydały Wasze podpowiedzi (szczególnie
> Twoja uwaga Bart). Aż mi znowu wstyd, że piszę na tę grupę.
>
> --
> królewna
>
Oczywiście chodziło mi o uwagę Daniela (choć uwaga Barta była 
bezpośrednią odpowiedzią na moje pytanie bez próby interpretacji :)). I 
właśnie w tej sprawie piszę.

Na końcu wspomniałeś coś o lockach. Ja chcąc kasować procesy z listy 
niby je usuwam ale pamięć przez nie zajmowana dalej pozostaje zajęta. 
Gdy drukuje sobie procesy, które dalej tkwią w pamięci przez 
gc.get_objects() zauważam, że jest tam rzeczywiście sporo locków (nie 
wiem jakich ani od czego bo ja żadnych nie tworzę).

Głównie zależy mi na tym aby zwolnić pamięć zajętą przez te wątki gdyż 
będą one tworzone dynamicznie i z czasem jeśli nie nastąpi zwolnienie, 
python po prostu zawali mi całą pamięć.

Przykładowo kod:

def a(i):
	pass

ko = []

for i in range(0, 100000):
	ko.append(threading.Thread(target=a, args=(1,)))
for i in ko:
	i.start()
	i.join()
for i in range(0,100000):
	k = ko.pop()
	del k
del ko

powoduje zajęcie prawie 170MB pamięci.

--
królewna

On 27.01.2010, królewna <krolewna@ee.pl> wrote:
> Na końcu wspomniałeś coś o lockach. Ja chcąc kasować procesy z listy 
> niby je usuwam ale pamięć przez nie zajmowana dalej pozostaje zajęta. 
> Gdy drukuje sobie procesy, które dalej tkwią w pamięci przez 
> gc.get_objects() zauważam, że jest tam rzeczywiście sporo locków (nie 
> wiem jakich ani od czego bo ja żadnych nie tworzę).
Ja pisałem o innych lockach. Jeśli wątki mają macać obiekt dostępny dla nich
wszystkich, to trzeba blokować (np. poprzez threading.Lock()) aby mieć pewność,
że tylko jeden wątek będzie operował na obiekcie w tym samym czasie.

> Głównie zależy mi na tym aby zwolnić pamięć zajętą przez te wątki gdyż 
> będą one tworzone dynamicznie i z czasem jeśli nie nastąpi zwolnienie, 
> python po prostu zawali mi całą pamięć.
>
> Przykładowo kod:
>
> def a(i):
> 	pass
>
> ko = []
>
> for i in range(0, 100000):
> 	ko.append(threading.Thread(target=a, args=(1,)))
> for i in ko:
> 	i.start()
> 	i.join()
> for i in range(0,100000):
> 	k = ko.pop()
> 	del k
> del ko
>
> powoduje zajęcie prawie 170MB pamięci.
Wywołanie "del" nie gwarantuje Ci, że usuwany obiekt zwolni w tym
czasie pamięć. Nastąpi to dopiero wtedy, kiedy GC uzna, że można to zrobić
(jeśli będą jakieś zapętlone referencje, to może to nigdy nie nastąpić).
"del" jedynie oznacza dany obiekt jako nieużywany.

A co do kodu, to trochę źle to robisz. Popatrz na coś takiego:



class MyThread(threading.Thread):
    def __init__(self, arg):
	threading.Thread.__init__(self)
	self.arg = arg

    def run(self):
	do_something_with(self.arg)


ko = []
for i in xrange(100000):
    ko.append(MyThread(1))
    ko[-1].start()

while len(ko):
    thr.join(0.25)
    if not thr.isAlive():
        ko.remove(thr)



Jeśli masz jakieś pytania do powyższego przykładu, daj znać.



Pozdrawiam
Beorn

-- 
Daniel 'Beorn' Mróz <beorn@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+                           ]

królewna napisał(a):

> Glownie zalezy mi na tym aby zwolnic pamiec zajeta przez te watki gdyz
> beda one tworzone dynamicznie i z czasem jesli nie nastapi zwolnienie,
> python po prostu zawali mi cala pamiec.
>
> Przykladowo kod:
>
> def a(i):
> 	pass
>
> ko = []
>
> for i in range(0, 100000):
> 	ko.append(threading.Thread(target=a, args=(1,)))
> for i in ko:
> 	i.start()
> 	i.join()
> for i in range(0,100000):
> 	k = ko.pop()
> 	del k
> del ko
>
> powoduje zaj�cie prawie 170MB pami�ci.

Mam dziwne wrazenie, ze brniesz w slepa uliczke.
Tworzenie 100000 watkow nie ma najmniejszego sensu w zadnym wypadku.
Moze przybliz troche co probujesz tak naprawde osiagnac,
a pewnie znajdziemy jakies rozwiaznie.
Zwykle takim rozwiazaniem jest tworzenie puli (dla kilku lub
kilakunastu)
watkow przy pomocy `Queue`.
To Cie moze zainteresowac:
http://rwdev.eu/articles/threads

RW

W dniu 27.01.2010 14:34, Rob Wolfe pisze:

> Mam dziwne wrazenie, ze brniesz w slepa uliczke.
> Tworzenie 100000 watkow nie ma najmniejszego sensu w zadnym wypadku.

To było robione tylko dla testów aby sprawdzić czy gc zwolni pamięć. Jak 
się okazuje nie zwalnia.

> Moze przybliz troche co probujesz tak naprawde osiagnac,
> a pewnie znajdziemy jakies rozwiaznie.

Mam zaimportowane moduły w liście i w zależności od aktualnych wymagań, 
chcę startować wątek z odpowiednim modułem. Tych wątków nie będzie 
dziesięć tysięcy bo to zabiłoby każdą maszynę aczkolwiek ich liczba 
będzie oscylować gdzieś w granicach 100 maksymalnie. Dlatego tworzenie 
na starcie puli wątków nie za bardzo wchodzi w grę (musiałabym 
uruchamiać 100*liczba_modułów wątków). Wydaje mi się, że w tej sytuacji 
lista wątków byłaby dobrym rozwiązaniem gdybym wiedziała jak zwolnić 
pamięć zajmowane przez wątki, które już wykonały swoją pracę i zostały 
usunięte z listy.

--
królewna

królewna napisał(a):
> W dniu 27.01.2010 14:34, Rob Wolfe pisze:
>
> > Mam dziwne wrazenie, ze brniesz w slepa uliczke.
> > Tworzenie 100000 watkow nie ma najmniejszego sensu w zadnym wypadku.
>
> To bylo robione tylko dla testow aby sprawdzic czy gc zwolni pamiec. Jak
> sie okazuje nie zwalnia.

Zwalnia, ale to nie oznacza, ze ta pamiec natychmiast wraca do
systemu.
Interpreter sobie zarzadza do pamiecia po swojemu i np. trzyma
do ponownego wykorzystania. W przypadku zarzadzania samymi
watkami pamiec nie powinna byc problemem.

>
> > Moze przybliz troche co probujesz tak naprawde osiagnac,
> > a pewnie znajdziemy jakies rozwiaznie.
>
> Mam zaimportowane moduly w liscie i w zaleznosci od aktualnych wymagan,
> chce startowac watek z odpowiednim modulem. Tych watkow nie bedzie

Skoro moduly sa zaimportowane, to sa dostepne globalnie i to ile
tych modulow jest nie powinno miec wplywu na liczbe watkow.

> dziesiec tysiecy bo to zabiloby kazda maszyne aczkolwiek ich liczba
> bedzie oscylowac gdzies w granicach 100 maksymalnie. Dlatego tworzenie

Wlasnie tego nie rozumiem. Skad ta liczba 100?

> na starcie puli watkow nie za bardzo wchodzi w gre (musialabym
> uruchamiac 100*liczba_modulow watkow). Wydaje mi sie, ze w tej sytuacji
> lista watkow bylaby dobrym rozwiazaniem gdybym wiedziala jak zwolnic
> pamiec zajmowane przez watki, ktore juz wykonaly swoja prace i zostaly
> usuniete z listy.

Liczbe watkow powinny determinowac zadania jakie maja
wykonywac, a nie liczba dostepnych modulow czy funkcji.
W tej konkretnej sytuacji wyobrazam to sobie tak:
1. pracuje sobie 10 watkow
2. przychodzi wymaganie A
3. z puli watek 1 rusza do akcji, na wejsciu dostaje info
    jakiego modulu ma uzyc
4. przychodzi wymaganie B
5. z puli watek 2 rusza do akcji
6. watek 1 konczy prace i czeka na wymaganie C

Gdy watki sie nie wyrabiaja, to lekki zwiekszam pule,
a jak czekaja bezczynnie, to zmniejaszam itd.

RW

On Jan 27, 4:19 pm, Rob Wolfe <r...@smsnet.pl> wrote:
> > na starcie puli watkow nie za bardzo wchodzi w gre (musialabym
> > uruchamiac 100*liczba_modulow watkow). Wydaje mi sie, ze w tej sytuacji
> > lista watkow bylaby dobrym rozwiazaniem gdybym wiedziala jak zwolnic
> > pamiec zajmowane przez watki, ktore juz wykonaly swoja prace i zostaly
> > usuniete z listy.
>
> Liczbe watkow powinny determinowac zadania jakie maja
> wykonywac, a nie liczba dostepnych modulow czy funkcji.
> W tej konkretnej sytuacji wyobrazam to sobie tak:
> 1. pracuje sobie 10 watkow
> 2. przychodzi wymaganie A
> 3. z puli watek 1 rusza do akcji, na wejsciu dostaje info
>     jakiego modulu ma uzyc
> 4. przychodzi wymaganie B
> 5. z puli watek 2 rusza do akcji
> 6. watek 1 konczy prace i czeka na wymaganie C
>
> Gdy watki sie nie wyrabiaja, to lekki zwiekszam pule,
> a jak czekaja bezczynnie, to zmniejaszam itd.

W zasadzie racja, aczkolwiek można użyć greenletów i zamiast puli po
prostu tworzyć wątek per zadanie.

W dniu 27.01.2010 16:19, Rob Wolfe pisze:

>
> Zwalnia, ale to nie oznacza, ze ta pamiec natychmiast wraca do
> systemu.
> Interpreter sobie zarzadza do pamiecia po swojemu i np. trzyma
> do ponownego wykorzystania. W przypadku zarzadzania samymi
> watkami pamiec nie powinna byc problemem.
>
Więc to, że interpreter trzyma 170MB pustej pamięci zarezerwowanej jest 
w porządku? To jaka jest graniczna ilość pamięci, przy której uzna, że 
rezerwacja nie ma sensu i zwolni pamięć? Skąd mam wiedzieć kiedy mam 
wyciek pamięci a kiedy po prostu GC robi sobie optymalizację przez 
"rezerwację"?

>
> Skoro moduly sa zaimportowane, to sa dostepne globalnie i to ile
> tych modulow jest nie powinno miec wplywu na liczbe watkow.
>
OK, źle Cię zrozumiałam. Masz rację.

>
> Wlasnie tego nie rozumiem. Skad ta liczba 100?
>
Założenie na podstawie tego co program ma robić.


>
> Liczbe watkow powinny determinowac zadania jakie maja
> wykonywac, a nie liczba dostepnych modulow czy funkcji.
> W tej konkretnej sytuacji wyobrazam to sobie tak:
> 1. pracuje sobie 10 watkow
> 2. przychodzi wymaganie A
> 3. z puli watek 1 rusza do akcji, na wejsciu dostaje info
>      jakiego modulu ma uzyc
> 4. przychodzi wymaganie B
> 5. z puli watek 2 rusza do akcji
> 6. watek 1 konczy prace i czeka na wymaganie C
>
> Gdy watki sie nie wyrabiaja, to lekki zwiekszam pule,
> a jak czekaja bezczynnie, to zmniejaszam itd.
Tyle, że zadań może przyjść 100 na raz i wszystkie powinny być obsłużone 
jednocześnie. Więc owszem - mogę trzymać jakąś standardową liczbę wątków 
ale i tak muszę mieć możliwość dodania dodatkowych wątków. Oczywiście 
może się zdarzyć tak, że będzie 101 lub 102... itd  zadań i wszystkie 
powinny być obsłużone jednocześnie. Miluśko by było gdyby te wątki miały 
jeszcze priorytety ale to już raczej extra funkcjonalność więc na razie 
mnie to nie interesuje.

--
królewna

królewna napisał(a):
> W dniu 27.01.2010 16:19, Rob Wolfe pisze:
>
> >
> > Zwalnia, ale to nie oznacza, ze ta pamiec natychmiast wraca do
> > systemu.
> > Interpreter sobie zarzadza do pamiecia po swojemu i np. trzyma
> > do ponownego wykorzystania. W przypadku zarzadzania samymi
> > watkami pamiec nie powinna byc problemem.
> >
> Wiec to, ze interpreter trzyma 170MB pustej pamieci zarezerwowanej jest
> w porzadku?

A kto powiedzial, ze w porzadku? ;)
Zarzadzanie pamiecia, to jest zawsze kompromis pomiedzy
wydajnoscia, a zuzyciem zasobow. Nie mozna miec jednego
i drugiego na najwyzszym poziomie.

> To jaka jest graniczna ilos pamieci, przy ktorej uzna, ze
> rezerwacja nie ma sensu i zwolni pamiec? Skad mam wiedziec kiedy mam
> wyciek pamieci a kiedy po prostu GC robi sobie optymalizacje przez
> "rezerwacje"?

Do tego wlasnie sluza profilery samego GC:
http://teethgrinder.co.uk/perm.php?a=Python-memory-leak-detector
Obserwowanie procesu z poziomu samego systemu daje
czasem mylny obraz.

>
> >
> > Skoro moduly sa zaimportowane, to sa dostepne globalnie i to ile
> > tych modulow jest nie powinno miec wplywu na liczbe watkow.
> >
> OK, zle Cie zrozumialam. Masz racje.
>
> >
> > Wlasnie tego nie rozumiem. Skad ta liczba 100?
> >
> Zalozenie na podstawie tego co program ma robic.
>

Nie chcesz mowic, to nie mow. ;)

[...]

> > Gdy watki sie nie wyrabiaja, to lekki zwiekszam pule,
> > a jak czekaja bezczynnie, to zmniejaszam itd.
> Tyle, ze zadan moze przyjsc 100 na raz i wszystkie powinny byc obsluzone
> jednoczesnie. Wiec owszem - moge trzymac jakas standardowa liczbe watkow

Co to znaczy jednoczesnie? Dysponujesz 100 procesorowa maszyna?
Poza tym mam nadzieje, ze jestes swiadoma istnienia GIL-a:
http://docs.python.org/glossary.html?highlight=gil#term-global-interpreter-lock

> ale i tak musze miec mozliwosc dodania dodatkowych watkow. Oczywiscie
> moze sie zdarzyc tak, ze bwdzie 101 lub 102... itd  zadan i wszystkie
> powinny byc obsluzone jednoczesnie. Milusko by bylo gdyby te watki mialy
> jeszcze priorytety ale to juz raczej extra funkcjonalnosc wiec na razie
> mnie to nie interesuje.

Odpalenie 100 watkow doprowadzi do dwoch rzeczy:
a) zarzniecia maszyny
b) narzut na synchronizacje miedzy watkami spowolni program
wielokrotnie

Pule watkow zostaly wymyslone, aby powyzszych problemow uniknac.
Tyle z mojej strony, nie chce Cie na sile do tego przekonywac.
Zrobisz jak uwazasz.

RW

królewna wrote:
>> Zwalnia, ale to nie oznacza, ze ta pamiec natychmiast wraca do
>> systemu.
>> Interpreter sobie zarzadza do pamiecia po swojemu i np. trzyma
>> do ponownego wykorzystania. W przypadku zarzadzania samymi
>> watkami pamiec nie powinna byc problemem.
>>
> Więc to, że interpreter trzyma 170MB pustej pamięci zarezerwowanej jest 
> w porządku? To jaka jest graniczna ilość pamięci, przy której uzna, że 
> rezerwacja nie ma sensu i zwolni pamięć? 

Zapewne niegdy nie uzna. Choćby dla tego że leżący pod spodem runtime 
języka C (to jest CPython) nigdy nie uzna.

> Skąd mam wiedzieć kiedy mam 
> wyciek pamięci a kiedy po prostu GC robi sobie optymalizację przez 
> "rezerwację"?

Trzeba spytać GC co widzdzi. Zobacz co masz w module gc, np. 
gc.get_objects() gc.garbage itp.

Wycieki są 2 rodzajów:
1. Wyciek "kasyczny" czyli to co trafiło do gc.garbage (obiekty w 
cyklach referencji posiadające metodę __del__)
2. Wyciek semantyczny, czyli obiekty które formalnie nie wyciekły, bo są 
trzymane przez jakieś struktury programu tyle, że są trzymane bez sensu.

[...]

pzdr
\SK

-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

W dniu 28.01.2010 12:51, Rob Wolfe pisze:
>
> Co to znaczy jednoczesnie? Dysponujesz 100 procesorowa maszyna?
> Poza tym mam nadzieje, ze jestes swiadoma istnienia GIL-a:
> http://docs.python.org/glossary.html?highlight=gil#term-global-interpreter-lock
>
Wątki i tak byłyby odpalane praktycznie na jednym rdzeniu gdyż jak sam 
zauważyłeś istnieje coś takiego jak GIL (którego istnienia jestem 
świadoma). A w tym kontekście jednoczesne oznacza jednoczesne odpalenie 
przez interpreter (zakładam, że wątki mogą odpalać się nawet do 10 
sekund). A wieloprocesowość mnie nie za bardzo interesuje.

>
> Odpalenie 100 watkow doprowadzi do dwoch rzeczy:
> a) zarzniecia maszyny
> b) narzut na synchronizacje miedzy watkami spowolni program
> wielokrotnie
Gdybym chciała coś liczyć na watkach to owszem - byłby to problem. 
Jednak wątki te będą bardziej nastawione na użycie I/O (które nota bene 
także nie będzie wielkie). Narzut na synchronizację nie będzie chyba 
jednak tak wielki przy 100 wątkach gdyż z tego co czytałam to GIL jest 
dosyć prosty w założeniu (choć przy mojej małej wiedzy z tego zakresu 
mogę się mylić).

>
> Pule watkow zostaly wymyslone, aby powyzszych problemow uniknac.
> Tyle z mojej strony, nie chce Cie na sile do tego przekonywac.
> Zrobisz jak uwazasz.
Im więcej o nich mówisz tym bardziej jestem do nich przekonana. Tylko 
mam problem z użyciem puli, gdyż może się okazać, że dany wątek będzie 
potrzebował 10 minut na zakończenie swojej pracy. Jeślibym założyła, że 
mam 10 wątków w puli, to może zdarzyć się tak, że wszystkie są 
zablokowane przez najbliższe 5 minut a ja potrzebuje rozpoczęcia 
wykonania danego zadania najpóźniej minutę od nadejścia polecenia jego 
wykonania.

Także przykładowe 100 wątków nie będzie działało cały czas. Jest to 
tylko pesymistyczne założenie, że taka sytuacja może się zdarzyć.

Pokrótce:
1. Wykonywanie zadania nie może być rozpoczęte później niż minutę po 
jego nadejściu (problem: wszystkie wątki w puli mogą mieć odpalone 
zadania, które trwają np 30 minut - brak wolnych wątków na odpalenie 
kolejnych)
2. Zadania wykorzystują raczej I/O (i to w dosyć niskim stopniu)
3. Preferuję wątki gdyż przy procesach powstaje problem synchronizacji 
danych

--
królewna

W dniu 28.01.2010 14:38, Sebastian Kaliszewski pisze:

>
> Zapewne niegdy nie uzna. Choćby dla tego że leżący pod spodem runtime
> języka C (to jest CPython) nigdy nie uzna.
>
Więc program taki zajmie w końcu całą dostępną pamięć operacyjną? Nie da 
się tego uniknąć?

Jak do tej pory to wszystko sprowadza się do tego aby zwolnić pamięć 
zajętą przez listę "lista" w przykładowym programie:
/*******************************
def nierobnic():
	pass

lista = []

for i in range(0, 10000):
	lista.append(threading.Thread(target=nierobnic))
for i in range(0,10000):
	lista.pop()
gc.collect()
print gc.garbage
print gc.get_objects()
********************************/
  gc.garbage wyświetla pustą listę a gc.get_objects() wywala 
niebotycznie długą listę z różnymi obiektami.

--
królewna

W dniu 28.01.2010 14:38, Sebastian Kaliszewski pisze:
> królewna wrote:
>> Więc to, że interpreter trzyma 170MB pustej pamięci zarezerwowanej
>> jest w porządku? To jaka jest graniczna ilość pamięci, przy której
>> uzna, że rezerwacja nie ma sensu i zwolni pamięć?
>
> Zapewne niegdy nie uzna. Choćby dla tego że leżący pod spodem runtime
> języka C (to jest CPython) nigdy nie uzna.
>
Hmmm ciekawe zarządzanie tą pamięcią jest w pythonie. Teraz sprawdziłam, 
i gdy zamiast jednokrotnej alokacji takich wątków w tablicy robię 
alokację i zwolnienie w pętli  to rzeczywiście - interpreter nie alokuje 
dodatkowej pamięci za każdym razem.

Sprawdziłam także czy gc zwalnia w końcu pamięć. Po pewnym czasie jest 
zwalniana więc problemu nie ma. Po prostu robiłam za krótkie programy 
testowe, które nie mogły sprawdzić całości pracy interpretera i gc.

Jednym słowem wykazałam się nieznajomością działania gc (do tej pory 
raczej nie miałam do czynienia z gc - używałam raczej języków 
kompilowalnych).

--
królewna

królewna pisze:
> Jednym słowem wykazałam się nieznajomością działania gc (do tej pory 
> raczej nie miałam do czynienia z gc - używałam raczej języków 
> kompilowalnych).
> 
java też ma gc a jest językiem kompilowanym (do bytecodu, ale jest :) )

On 2010-01-29, koval <koval@USUNTOkonto.pl> wrote:
> królewna pisze:
>> Jednym słowem wykazałam się nieznajomością działania gc (do tej pory 
>> raczej nie miałam do czynienia z gc - używałam raczej języków 
>> kompilowalnych).
>> 
> java też ma gc a jest językiem kompilowanym (do bytecodu, ale jest :) )

W C++ też można używać garbage collectora.

-- 
Secunia non olet.
Stanislaw Klekot

On 28.01.2010 16:20, królewna wrote:
> Pokrótce:
> 1. Wykonywanie zadania nie może być rozpoczęte później niż minutę po
> jego nadejściu (problem: wszystkie wątki w puli mogą mieć odpalone
> zadania, które trwają np 30 minut - brak wolnych wątków na odpalenie
> kolejnych)
> 2. Zadania wykorzystują raczej I/O (i to w dosyć niskim stopniu)
> 3. Preferuję wątki gdyż przy procesach powstaje problem synchronizacji
> danych

To może jeden wątek + select / epoll (nie wiem ile masz tych fd), skoro 
przez większość czasu czekają na IO?

Pozdrawiam,
Cubix

królewna wrote:
>> Zapewne niegdy nie uzna. Choćby dla tego że leżący pod spodem runtime
>> języka C (to jest CPython) nigdy nie uzna.
>>
> Więc program taki zajmie w końcu całą dostępną pamięć operacyjną? Nie da 
> się tego uniknąć?

Nie, nie zajmie.

Zwolnienie pamięci przez kod użytkownika, nawet jawne zwolnienie i nawet 
w implementacjach języków takich ja C, Pascal, itp. nie oznacza oddania 
tej pamięci systemowi operacyjnemu. Pamięć jest przed kod użytkownika 
oddawana tylko do dyspozycji runtime języka, który udostępni tę pamięć 
ponownie gdy kod użytkownika znowu będzie "chciał" coś zaalokować. Tylko 
czasami, jeśli tej wolnej pamięci zbierze się dużo i to w dużym jednym 
kawałku, i runtime w ogóle przewiduje oddawanie pamięci do systemu 
(wcale częsyto nie pzewiduje w ogóle) to zostanie ona do systemu oddana.

pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)