Thready a signaly

[Petr Novotny]

Dobry den,

asi se dostavame trochu off-topic...

> A konkretne - pokud jde o utnuti threadu, tak se daji pro jednodusii
> pripady pouzit cleanup funkce (pthread_cleanup_push/pop - a pokud
> jste chtel vsechno uvolnovat v signal handleru tak to mozna je
> vhodne); pro slozitejsi (treba v C++ pri hojnym pouzivani STL
> kontejneru - muj pripad :]) si proste udelat vlastni mechanismus
> cancelovani a na pthread_cancel apod. se vykaslat.

Jakym zpusobem zajistim, ze "zakously" thread se sam utluce, mi neni 
jasne. Dovedu si predstavit nejaky vnejsi, tj. asynchronni, podnet. 
Dovedu si tez predstavit, ze po kazde instrukci (nebo kazdem druhem 
radku ve zdrojaku) se thread podiva, zda by nemel skoncit - jenze to 
za prve zdrzuje (ja vim, ja vim) a za druhe to neudelam, pokud 
nahodou musim volat funkce z cizi knihovny, kterou nesmim modifikovat 
a svoje kontroly tam pridavat. No a pokud se v te knihovne kousne...

Navic (nevim jak pod Linuxem, ale pod Win32 urcite) mohou existovat 
data (thread-local storage), na jejichz hodnotu se doptam pouze v 
kontextu daneho threadu (no a nebo v kernelu); pokud v techto datech 
je neco, co je treba uvolnit, musi to uvolnovani probehnout v 
kontextu daneho threadu - anebo program leakuje.

To, k cemu jsem puvodne smeroval: Thready jsou pekna vec. Jenze jim 
chybi (podle vseho, co jsem tu zatim slysel) moznost asynchronni 
komunikace... Pokud se pletu, budu rad, kdyz me opravite.

Navrhuji dalsi diskusi prenest do osobniho mailu...
--
Petr Novotny, ANTEK CS
Petr.Novotny na antek.cz
http://www.antek.cz
-- Don't you know there ain't no devil there's just God when he's drunk.
                                                             [Tom Waits]