<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Emanuele Zeppieri ha scritto:
<blockquote cite="mid000b01c73307$cf949f80$1400000a@main" type="cite">
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:roma-bounces+ema_zep=libero.it@pm.org">roma-bounces+ema_zep=libero.it@pm.org</a>
[<a class="moz-txt-link-freetext" href="mailto:roma-bounces+ema_zep=libero.it@pm.org">mailto:roma-bounces+ema_zep=libero.it@pm.org</a>] On Behalf Of
Alessandro Merlani
Sent: Monday, January 08, 2007 4:27 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:roma@pm.org">roma@pm.org</a>
Subject: Re: [Roma.pm] SIGKILL
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">veramente io non so neanche di che caso stiamo parlando,
</pre>
</blockquote>
<pre wrap=""><!---->
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).
</pre>
<blockquote type="cite">
<pre wrap="">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;
</pre>
</blockquote>
<pre wrap=""><!---->
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 ;-)
</pre>
<blockquote type="cite">
<pre wrap="">un processo che riceve sigkill puo' tranquillamente
ignorarlo, stante il fatto che
comunque il kernel uccidera' il processo
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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;
</pre>
</blockquote>
<pre wrap=""><!---->
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.
_______________________________________________
Roma mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Roma@pm.org">Roma@pm.org</a>
<a class="moz-txt-link-freetext" href="http://mail.pm.org/mailman/listinfo/roma">http://mail.pm.org/mailman/listinfo/roma</a>
</pre>
</blockquote>
Bene quindi in conclusione un processo (facciamo un esempio in perl)
non può auto reinstanziarsi dopo un sigkill, ma al max deve essere
assistito da un processo che controlla lo stato dell'altro, giusto?<br>
</body>
</html>