[Roma.pm] SIGKILL
Emanuele Zeppieri
ema_zep at libero.it
Mon Jan 8 01:31:40 PST 2007
> -----Original Message-----
> From: roma-bounces+ema_zep=libero.it at pm.org
> [mailto:roma-bounces+ema_zep=libero.it at pm.org] On Behalf Of
> Alessandro Merlani
> Sent: Monday, January 08, 2007 4:27 AM
> To: roma at pm.org
> Subject: Re: [Roma.pm] SIGKILL
> veramente io non so neanche di che caso stiamo parlando,
Be', non sarebbe male informarsi, quando si entra in un thread ;-)
Si chiedeva se un sigkill potesse essere trappato o ignorato (dove per
ignorato si intende *ignorato permanentemente*, che significa, in altre
parole, che il processo possa continuare a compiere altre operazioni
dopo il recapito del sigkill).
> ho letto semplicemente la mail cui ho risposto e ho precisato
> che c'e' un caso in cui sigkill non ha effetto; volendo
> precisare ulteriormente non e' esatto dire
> che sigkill non e' ignorabile in quanto e' _sempre_
> ignorabile;
Niente affatto: "ignorabile" vuol dire "ignorabile permanentemente" o,
in altre parole, che tutto va esattamente come se il segnale non fosse
mai stato inviato al processo (nel seguito puoi trovare una definizione
piu` formale).
E vuol dire pure, per essere piu` chiari, che il processo puo`
continuare a fare esattamente quello che desidera.
Ora ti sembra forse che un processo in uninterruptible sleep a cui viene
inviato un sigkill possa continuare a fare quello che gli pare?!
Il sigkill al risveglio del processo verra` invariabilmente recapitato,
e il processo altrettanto invariabilmente verra` terminato (senza alcuna
possibilita` di ignorare il segnale).
Lo stato di uninterruptible sleep puo` al piu` causare un recapito
"ritardato" del segnale, ma si tratterebbe in ogni caso di un "ritardo"
del tutto particolare, cioe` un ritardo durante il quale il processo
comunque non avrebbe la possibilita` di compiere alcuna operazione.
Mi sembra impossibile non riuscire a cogliere la differenza (neanche
tanto sottile, per usare le tue stesse parole ;-)
> un processo che riceve sigkill puo' tranquillamente
> ignorarlo, stante il fatto che
> comunque il kernel uccidera' il processo
Non ho capito: il processo "ignora" il sigkill perche` tanto e` il
kernel che poi lo ammazza?! :-)
Se la butti sul piano filosofico-soggettivistico-interpretativo, i
concetti si possono estendere a piacimento e si puo` arrivare a
qualsiasi conclusione.
Purtroppo pero` in informatica le definizioni non hanno un valore
soggettivo, e "ignorare" un segnale vuol dire che, a discrezione del
processo e *non* del kernel, lo stato del processo viene ripristinato
esattamente allo stato precedente il recapito del segnale, e lo stato
della coda dei segnali del kernel viene ripristinato esattamente allo
stato precedente l'accodamento del segnale medesimo.
Quindi se il processo viene terminato d'imperio dal kernel, o se il
segnale viene accodato nel kernel in attesa che il processo target si
risvegli, il segnale _non_e`_ stato ignorato.
La differenza e` parossistica.
Poi se vuoi continuare a giocare con le parole, fai pure.
> > Al limite potrebbe
> > servire per "ritardarlo", ma sarebbe comunque un ritardo del tutto
> > inutile, giacche` il processo in sleep non potrebbe *fare nulla*,
> > perche` non appena dovesse risvegliarsi gli verrebbe subito
> > recapitato il sigkill.
>
> nessuno ha detto che un processo in status D e' un modo per
> evitare che il kernel lo ammazzi dopo un sigkill e permettergli
> di continuare a lavorare;
Non volevo attribuirti alcuna affermazione, ma questo era esattamente
l'argomento di si stava parlando: se esistesse un modo per permettere ad
un processo di effettuare operazioni (segnatamente reinvocare il
programma che lo aveva istanziato) anche dopo un sigkill.
Per questo dicevo che e` opportuno leggere i thread ai quali si intende
partecipare.
Ciao,
Emanuele.
More information about the Roma
mailing list