doruceni signalu KILL procesu ktery neprerusitelne spi

Divacky Roman xdivac02 at stud.fit.vutbr.cz
Wed Sep 10 11:23:57 CEST 2003


> 	Rozhodne bych nevolal endtsleep - je tam od stejneho ucelu label 
> "runfast" (takze goto runfast:) - nicmene, to je jen detail. At tak ci 
> onak je v obou pripadech proces oznacen jako "runnable".
 
pokud chapu dobre ten zdrojak tak runfast mi nepomuze...

> 	Tim se pri nejblizsim reschedulingu signal doruci a spusti se 
> 	obsluzna rutina, ktera je pro SIG_KILL vzdycky SIG_DFL, co znamena volani 
> sigexit() coz vyusti v exit1()
> 
> 	V ramci te se volaji "exit_list" funkce, uzaviraji otevrene soubory, 
> posilaji signaly odvozenym procesum.
> 
> 	Pri tom je mozne, ze se nektere funkce a akce volaji pod zamkem  - a 
> 	to bud globalnim nebo lokalnim. Pokud i puvodni tsleep byl volan pod 
> zamkem, pak muze dojit k dead-locku.

to je taky mozne... dozvedel jsem se ale jiny problem: co kdyby se to IO po
killnuti toho procesu dodelalo... zapsalo by to nejaka data nekam a mohl by byt
prusvih... jeste mne poradne nenapadlo jak to eliminovat a mam dojem ze to asi
nepujde...

snad by slo nejak si zachovat puvodni VM a tracovat tam ruzne veci (at uz ty
zamky, ci buffery) ale vypada to dost slozite az nepouzitelne
 
> 	Nevim, jestli jsem v predestrene uvaze neudelal nekde fatalni chybu 
> 	- ale zda se mi, ze takhl ejednoduse opravitelny problem to nebude.
> 
> 	Ja bych spis smeroval k tomu eliminovat v systemu volani tsleep bez 
> timeoutu a osetrit pripadny timeout tam vznikly (po opatrne uvaze, zda 
> lze v tomto miste vubec takovou situaci pripustit) - samozrejme s tim, 
> ze je treba tim se vec opravi na kazdem konkretnim miste pricemz riziko, 
> ze zmena zasahne cely system je male.

dost dobre nechapu jaky je rozdil zrusit timeout ve zdrojaku a zrusit ho tim
SIGKILLEM (endtsleep v podstate prerusi spani - tj. vlastne timeout, ne?)
 
> 	Nicmene, je opravdu mozne, ze jsem neco prehledl a k dead-locku 
> 	dojit nemuze - pak by ten zasah mozna mozny byl.
> 
tech problemu se objevilo vic takze je to nejspis spatna cesta
kazdopadne moc diki za pripominku!!!

roman



More information about the Users-l mailing list