[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