Zhrouceni Xorg a zmizeni konzole

Divacky Roman xdivac02 at stud.fit.vutbr.cz
Tue May 9 15:49:37 CEST 2006


On Mon, May 08, 2006 at 09:46:09PM +0200, Dan Lukes wrote:
> Pav Lucistnik napsal/wrote, On 05/08/06 20:36:
> >> > issue_read_comand();
> >> > sleep();		/* cekame na az na interrupt oznami ze bylo precteno */
> >> > blah();
> >> > 
> >> > coz funguje tak ze se nejdriv posle prikaz na cteni do disku a pak se ten
> >> > proces blokne (coz dela ten sleep) a ceka se nez se odblokuje, a pokud to nema
> >> > nejaky timeout tak tak bude blokovany naporad a nepujde to killnout pac kill je
> >> > signal a ten se zpracovava jen pri context switchi ke kteremu tady nikdy
> >> > nedojde...
> >> 
> >> 	A opravdu, to ci rikas, plati i pro SIGKILL, o kterem tu byla rec ?
> > 
> > Signal jako signal, ano, plati to i pro signal cislo devet.
> 
> 	Ale to jo - tomu rozumim. Roman predpoklada, ze system je ve stavu, kdy 
> je *zakazany context switch* (prichodem signalu se ten sleep prerusi a 
> pokud by switch zakazany nebyl, tak by se SIGNAL prislusne zpracoval.

scheduler ma nekolik seznamu procesu, (runnable, blocked atd.) a kdyz je proces
v tom blocked tak na neho scheduler kasle a vubec se neobtezuje ho schedulovat
takze zadny context-switch se ho netyka...

moc se mi to chovani nelibi pac nemoznost killnout nektere procesy je dost blba
;( premyslim o tom ze by se dalo udelat neco co by treba jednou za 10 sekund
(tj. nulovy overhead) proslo blocked procesy a zjistilo jestli jim nependuje
SIGKILL a jestli jo tak ho wakeuply... ale asi ma tento pristup nejake vady pac
jinak by to uz nekdo udelal ;(



More information about the Users-l mailing list