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