[Roma.pm] SIGKILL

LordOfDeath webmaster.staff at gmail.com
Mon Jan 8 01:49:27 PST 2007


Emanuele Zeppieri ha scritto:
>> -----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.
>
> _______________________________________________
> Roma mailing list
> Roma at pm.org
> http://mail.pm.org/mailman/listinfo/roma
>
>   
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/roma/attachments/20070108/e0fcffe4/attachment.html 


More information about the Roma mailing list