doruceni signalu KILL procesu ktery neprerusitelne spi
Dan Lukes
dan at obluda.cz
Mon Sep 8 13:16:51 CEST 2003
Divacky Roman wrote:
> muze se stat (a parkrat se mi to i stalo) ze proces usne pri cekani na
> nejakou HW udalost, ktera se proste nestane (HW porucha - u mne konkretne
> dosluhujici cdromka) a tak zustane vyset... neprisel jsem na zpusob jak
> ten proces "odstrelit" (pokud ot nejak jde uvitam radu!), pze kdyz mu
> poslu signal KILL tak ten se zpracuje az po dokonceni te udalosti na
> kterou ceka ten sleep (tj. po ubehnuti timeoutu nebo nikdy)
>
> napadlo mne jedine reseni - zaridit aby KILL prerusil ten tsleep() a
> zpracoval se normalne...
> nemuzu na tom najit nic spatneho (na te myslence) a tak by mne zajimalo
> jestli nekoho neco napadne... tj. napada nekoho proc by se nemelo tomu
> KILLu dovolit prerusit ten sleep
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".
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.
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.
Nicmene, je opravdu mozne, ze jsem neco prehledl a k dead-locku dojit
nemuze - pak by ten zasah mozna mozny byl.
Dan
More information about the Users-l
mailing list