doruceni signalu KILL procesu ktery neprerusitelne spi

[Dan Lukes]

Divacky Roman wrote:

> uvazoval jsem o tom a prisel jsem na tohle:
> 
> kdyz prerusim ten tsleep tak se vrati s nejakou error hodnotou, coz pri typicke
> konstrukci
> 
> neco();
> if (nekde_neco){
>    tsleep(nekde...);
> }
> neco_dalsiho();
> 
> by melo byt schopno osetrit to, ze ten tsleep neuspel a zachovat se podle toho
> (tj. odemcit zamky atd. jaks popisoval predtim) - podle nastaveni nekde_neco

	Pokud se bavime stale o SIGKILL, pak kod programu uz nema dostat 
rizeni. Je tedy celkem lhostejne, co se za volanim tsleep nachazi a zda 
jsou tak ci onak osetrene nejake navratove kody.

	Problem je s "post-KILL" cleanupem - zavirani souboru, soketu 
odalokovavani pameti a jinych zdroju, ktere proces pouzival.

> doopravdy jediny problem ted zustava to, co by se stalo kdybych killnul proces
> ktery dela nejake IO v tom tsleepu a po killnuti toho procesu to IO nakonec
> uspelo - zapise to neco nekam -> problem

	V tsleepu se nic nedela - tam se jen ceka na udalost. Jinak ale mate 
pravdu - komplikace spociva proste v tom, ze "neprerusitelny" tsleep se 
nedela pro nic za nic - ten se dela u takovych veci, kde je nepripustne, 
aby byla akce prerusena. A vy ji chcete prerusit a provest cleanup - 
jenze ten nemusi byt, za aktualniho stavu systemu, mozny.

	Namatkou me napada vznik dead-locku nad nejakymi systemovymi zamky.

> 1) pockat, zadna IO netrva dele jak rekneme x sekund (to je ale dost hloupe)
> 2) nejak odtracovat ktere IO se zavolalo a osetrit to (bohuzel to nemam poneti
> jak by se dalo nejak inteligentne udelat)

	I analyzu, ze se neprerusitelny tsleep pouziva jen pri cekani na IO je 
nutne udelat - ja to nevidim jako trivialni tvrzeni ...

> 3) nechat si z procesu vm_space a udelat z nej neco jako kernelovy "/dev/null"
> (tj. zapis nic neudela, cteni vraci nulu) - to ovsem dost dobre nevim jak delat

	To by, v zasade, asi nebyl problem - jenze je otazka, co jste tim 
dosahl. Proces v tomto stavu stale existuje (kvuli evidentci onoho 
vm_space) ale uz nedostane rizeni. To je shodne se soucasnym stavem. 
Jediny rozdil ve vasem pripade je pamet je fakticky  uvolnena, kdezto v 
soucasnem stavu je (typicky) odswapovana na disk (kde je mista dost).


	Dalsi problem je prave "post-exit" cleanup. Patrne i v tomto systemu 
budete chtit uvolnit procesem uzivane zdroje. Bud' to udelate po 
skonceni onoho tsleepu (pak je to ale shodne se soucasnou situaci), tedy 
shodnym postupem jako v soucasne dobe (a jen tezko lze hovorit o 
likvidaci procesu), nebo je budete chcit udelat hned - a je treba 
opatrne analyzy, zda je skutecne bezpecne "behem" preruseneho 
neprusitelneho tsleepu volat systemove funkce, coz je nutnou soucasti 
clean-upu (mohly by pri tom byt uvolneny zdroje, ktere byly alokovany ku 
prilezitosti vyrizovani neceho, na co ten tslep ceka - a nejde jen o pamet).

	A bez toho vam ten proces stale zustane "nezastrelitelnym" procesem az 
do konce behu systemu tak jako tak.

							Dan