Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Řešení dotazu:
Proste killnu kate, at si zavisi na cem chce a nazdar s nim ne?Tipuju, že zrovna může mít zamčený nějaký zámek v kernelu, a ten pak zůstane zamčený navždy? Netuším, jak jsou věci v kernelu implementované, ale asi nebude obecně pravda, že je lze kdykoli zabít. Ale možná by mohl být nějaký override "ano, opravdu zabít".
Když tedy udělám proces, který se záměrně bude dostávat do stavu D, zabiju tím systém?
To není tak jednoduché, rozhodnutí, zda bude proces spát přerušitelně ("S", TASK_INTERRUPTIBLE
) nebo nepřerušitelně ("D", TASK_UNINTERRUPTIBLE) je na kódu jádra, který se ho rozhodne při čekání uspat. Uninterruptible sleep se typicky používá tam, kde se neočekává, že se bude čekat moc dlouho, a úklid stavu při přerušení by byl komplikovaný.
Tohle jsem nikdy nepochopil, proč jádro prostě nemůže ten čekající proces utnout a vyhodit natvrdo.
Např. proto, že ten proces drží nějaký mutex, takže kdyby se jen tak "odstřelil", jak si představujete, zůstal by ten mutex natrvalo zamčený a každý proces, který by si ho potřeboval vzít, by se od té chvíle "seknul" úplně stejný. (Mohou být i jiné důvody, ale tohle je doufám dostatečně názorné.)
Na druhou stranu, už poměrně dlouho lze použít TASK_KILLABLE
, kdy je sice stále blokovaná většina signálů, ale proces lze zabít pomocí SIGKILL
. Používá se tam, kde je sice žádoucí, aby byl spánek nepřerušitelný běžnými signály, ale proces lze v případě potřeby bezpečně zabít. Na výstupu ps
nebo top
to ale poznat není, oboje se ukazuje jako "D".
To hlavní, co je potřeba mít na paměti, je, že uninterruptible sleep není samoúčelný, vývojáři ho nepoužívají, pokud k tomu nemají dobrý důvod. Také by v tomto stavu proces neměl být dlouho a pokud je, znamená to, že je něco špatně. Buď došlo k deadlocku (což znamená bug) nebo je systém z nějakého důvodu přetížený, např. příliš mnoho konkurenčních požadavků na stejné I/O zařízení nebo příliš plná paměť (a neustálé čekání, až se něco "odswapuje", aby se uvolnily stránky potřebné pro aktuálně běžící procesy).
Coz je nesmysl, protoze pokud by mutex respektoval to, kdo ho vytvoril, tak sestreleny proces, pokud prestane existovat, by uz dany mutex proste nedrzel a operace by byla vyrizena, vysledek nepotrebny, tedy mutex by se mohl s klidem odmutexovat a dalsi procesy by mohly nerusene dal fungovat. Vysledek IO operace uz v takovem pripade nikdo nepotrebuje. Neco jak kdyz v jistych jazycich otevru a zamknu soubor a skoncim bez uzavreni a odemceni, taky nezustane natrvalo takovy soubor zamceny a otevreny, neb by to delalo dost bordel a komplikace v systemu takove chovani. A proste stav D je komplikace vcelku radna nekdy. Napriklad u toho kate se seklym sshfs totiz dalsi spusteny kate je sekly taky i kdyz sshfs uz bezi novy a funkcni. A ja si osobne myslim, ze jadro by melo byt chytrejsi nez aplikace a nenechat se aplikaci jakkoliv rozrusit, takze by melo mit moznost zabit proces at se deje co se deje. Jinak to muze skoncit uplnym zahlcenim systemu, pokud to aplikace budou delat naschval, tedy za ucelem dostat mnoho svych procesu do stavu D.Např. proto, že ten proces drží nějaký mutex, takže kdyby se jen tak "odstřelil", jak si představujete, zůstal by ten mutex natrvalo zamčený a každý proces, který by si ho potřeboval vzít, by se od té chvíle "seknul" úplně stejný. (Mohou být i jiné důvody, ale tohle je doufám dostatečně názorné.)
Pokud na toto téma chcete opravdu diskutovat a ne jen hořekovat nad tím, jak je jádro úplně špatně navržené, bylo by vhodné, abyste si pro začátek nastudoval aspoň něco málo o tom, jak ty věci fungují a proč. Ono by sice teoreticky bylo možné, aby mutex opravdu fungoval tak, jak si to představujete, ale existují dobré praktické důvody, proč to tak není (především efektivita).
A proste stav D je komplikace vcelku radna nekdy.
Zkusím to vysvětlit ještě jednodušeji: to, že nějaký proces setrvává delší dobu v "D" stavu, není skutečný problém, ale jen symptom (a důsledek) vážnějšího problému někde jinde. Ať už je tím problémem bug nebo prostě jen přetížení určité části systému a ať už je problém trvalý nebo jen dočasný, měl byste řešit ten skutečný problém, ne nějaký "stav D". Stejně jako když vám dojde místo na filesystému, začnou vám různé programy hlásit podivné chyby, protože nemají kam zapisovat data; ale problémem nejsou chybová hlášení těch programů, skutečný problém je plný filesystém. Tohle je úplně stejné.
tak sestreleny proces, pokud prestane existovat, by uz dany mutex proste nedrzel a operace by byla vyrizena, vysledek nepotrebny, tedy mutex by se mohl s klidem odmutexovat a dalsi procesy by mohly nerusene dal fungovatCo když to byla zapisovací IO operace a proces zrovna v okamžiku sestřelení modifikoval třeba nějaký B strom?
A co kdyby mu zrovna vypadla elektřina?
To je irelevantní. On je totiž ten Jendův příklad spíš zavádějící, důvod, proč je při určitých operacích potřeba mít TASK_UNINTERRUPTIBLE
(ale ne TASK_KILLABLE, zmínku o němž zatím všichni statečně ignorují) není nekonzistence data na disku, to by opravdu nedávalo smysl. Bývá to spíš nekonzistentní stav běžícího systému nebo nekonzistentní stav nějakého zařízení
. V takovém případě výpadek elektřiny, reset nebo panic nevadí, ale kdyby proces najednou "zmizel" be řádného úklidu, byl by to problém.
D stav je prostě špatné řešení teoretického problému.
Tak ještě jednou: TASK_UNINTERRUPTIBLE
není "špatné řešení", je to prostě stav. Stav, ve kterém jsou blokovány signály, nic víc, nic méně. Toho, co se musí provést při "odstřelení" procesu, je už takhle poměrně dost a kdyby bylo potřeba v kterémkoli okamžiku umožnit okamžité ukončení, mělo by to vliv na výkon, který je obecně považován za nepřijatelný.
A to se pořád ještě bavíme jen o TASK_UNINTERRUPTIBLE & !TASK_WAKEKILL
. Pokud to je možné, používá se TASK_KILLABLE = TASK_UNINTERRUPTIBLE | TASK_WAKEKILL
, kdy se sice blokují signály, ale proces lze ukončit pomocí SIGKILL
. On totiž zdaleka ne každý syscall vůbec počítá s tím, že může být přerušen signálem a vrátit EAGAIN
.
Ale především by asi bylo dobré znovu zopakovat poslední odstavec komentáře z 19.8. 12:35. A opakovat ho tak dlouho, dokud ho ti, kdo tu pořád opakují, jak je "stav D špatné řešení" nevstřebají.
Tím jen nepřímo říkáš, že systém je příliš křehký a ta či ona komponenta si neporadí s nekonzistentním stavem.
Klidně si tomu tak můžete říkat, pokud chcete. Samozřejmě že by se to teoreticky dalo udělat i tak, aby to fungovalo tak, jak si představujete, ale výsledek by byl zoufale neefektivní. Pro každý mutex byste musel někde zaregistrovat, že se má odemknout. Pro každou referenci, kterou může task v danou chvíli držet, byste musel někde zaregistrovat, že se má vrátit. Ale pozor, to všechno včetně těch, které držel už volající v úplně jiné části jádra, takže ta registrace by se pravděpodobně musela provést už při každém zamknutí mutexu nebo vzetí reference. Kdo má trochu představu, co obnáší zamknutí mutexu nebo refcount_inc()
, musí mu být jasné, že to je naprostý nesmysl, protože byste tím z jednoduché a efektivní operace udělal zoufale pomalého molocha. A to jsou jen dva triviální příklady, zrovna tak byste musel evidovat další spoustu zdrojů, a to nejen těch univerzálních, ale i různé specifické pro konkrétní subsystémy nebo drivery.
A i kdybyste to nakrásně realizoval a zbavil se všech uninterruptible sleepů, ve skutečenosti byste tím nevyřešil vůbec nic. Protože k tomu, aby proces byl "nesestřelitelný", totiž vůbec nepotřebujete ten uninterruptible sleep. Z úplně stejných důvodů (bug, nešťastný návrh nebo přetížení) může proces třeba čekat na spinlock; pak sice neuvidíte ten "ošklivý a chybně navržený stav D", budete tam mít nádherné "R", ale nesestřelitelný bude úplně stejně.
Možná by bylo lepší si připustit, že oni ti vývojáři jádra (a všech unixových OS před Linuxem a vedle něj) možná nejsou taková banda úplných pitomců, která za ty desítkly let nepochopila to, co je vám úplně jasné hned od pohledu.
TASK_KILLABLE
, o které jsem tu už několikrát zmínil a která se samozřejmě dávno používá - tam, kde je to možné a praktické. Takže mi zbývá jen upozornit, že ten článek je 13 let starý…
Ale především by asi bylo dobré znovu zopakovat poslední odstavec komentáře z 19.8. 12:35. A opakovat ho tak dlouho, dokud ho ti, kdo tu pořád opakují, jak je "stav D špatné řešení" nevstřebají.No ale tak pokud je to NFS nebo NBD na nějakém vzdáleném stroji, jehož výpadek nedokážu ovlivnit, a já teď mám kvůli tomu v počítači zaseknuté procesy, tak je to mrzuté.
Ano, to určitě dobré není, ale co si pamatuju, zrovna u NFS už to ve většině případů killable je. NBD je dost starý driver a ne zrovna mainstream, takže tam si nejsem moc jistý, jak moc aktivně je vyvíjený. Obecně samozřejmě souhlasím, že při čekání na odezvu ze sítě by se vždy mělo počítat s tím, že se nedočkáme, takže by tam vždy měl být nějaký (ideálně konfigurovatelný) timeout a možnost ručního zásahu (což nemusí být nutně zabití procesu signálem, u NFS mne napadá třeba forced unmount). Sám jsem se před lety dohadoval s autorem DRBD, že čekat na potvrzení od druhého serveru pod spinlockem je špatně; on argumentoval tím, že když to po nějakém timeoutu vzdáme (což už měl v novější verzi implementováno), tak vznikne split-brain, já se ho snažil přesvědčit, že když na to potvrzení čekáme šest hodin, tak ten split-brain už dávno nastal a je lepší si to připustit včas.
Ale podstata je někde jinde. Já přece netvrdím, že je všechno je napsáno dokonale a že některé konkrétní drivery nemohou používat unkillable uninterruptible sleep spíš z lenosti než ze skutečné potřeby. Jenže lidé jako Josef Kufner a "nemam" (a ti, kdo jejich stesky označují jako "řešení") tu tvrdí, že uninterruptible sleep je z principu špatně a že by neměl existovat vůbec. A navíc zarputile ignorují existenci dvou variant, z nichž pouze jedna se chová tak, jak tvrdí (přestože Josef Kufner sám nalinkoval 13 let článek informující o implementaci).
Zkuste si nejdřív přečíst, co už jsem sem na tohle téma napsal. Třeba si všimnete, že vůbe nejde nějaká "data ty aplikace", ale o interní datové struktury jádra, které nemůžete nechat v nekonzistentním stavu, protože pak by stejně šlo do kytek i všechno ostatní, stejně jako kdybyste nechal zamčené nějaké zámky nebo neuvolnil reference.
Ono je opravdu neuvěřitelně frustrující snažit se nějak technicky argumentovat a bavit se s bandou lidí, kteří nemají sebemenší představu, jak věci fungují a co by jejich geniální vize obnášely v praxi, ale o to silnější mají výrazivo a o to více házejí ramena, jak jsou všichni ti vývojáři naprostí blbci, když něco tak "jasného" nedokážou pochopit. A co hůř, libují si ve své ignoranci a nemají sebemenší snahu se o problematice něco dozvědět.
Takže této marné snahy o vysvětlování radši nechám a počkám si na vaše patche, které odstraní TASK_UNINTERRUPTIBLE
z linuxového jádra. Jak kdysi pravil jeden moudrý muž: "Tak is cheap. Show me the code."
Čistě ze zvědavosti… toho, že jsem tu už před více než pěti dny napsal
Obecně samozřejmě souhlasím, že při čekání na odezvu ze sítě by se vždy mělo počítat s tím, že se nedočkáme, takže by tam vždy měl být nějaký (ideálně konfigurovatelný) timeout a možnost ručního zásahu
jste si nevšiml nebo jste se to rozhodl ignorovat?
Je to stejný problém.Není, pokud jde o inmemory strukturu. Třeba pokud alokoval paměť (nevím jak funguje jaderný alokátor, ale tipuju, že multithread a nějakou potřebu zamykání mít bude), tak když vypadne proud, tak je to jedno. Předpokládám, že malloc (pomáhám si analogií z userspace, protože do kernelu nevidím) se žurnálem bys nechtěl, protože by byl pooomalý.
finally
). Pokud už to předalo procesu, tak se to uklidí při ukončení jako obvykle.
Nejde ani tak o technické detaily, ale o to, že se kdysi použilo nějaké řešení, později se ukázalo nešikovné, ale teď už je velmi obtížné ho změnit, protože je v daném projektu zažrané příliš hluboko, nejen v kódu, stabilních API, ale i v hlavách programátorů. Stává se to až nehezky často.
Pokud jádro něco alokuje či použije v rámci toho zaseknutého volání, tak o tom ví a může to uklidit (neboť to leží v té proměnné tam o pár řádek výše a "stačí" implementovat něco jako finally).Já tomu teda prd rozumím, ale myslel jsem si, že tam platí dvě věci:
ty operace nedělá nějak magicky „kernel“, ale přímo ten thread, který teď spouští kód kerneluTo je totéž. Prostě kus kódu v Ring 0, který po sobě musí umět uklidit, i když věci nedopadnou dobře.
Pokud jádro něco alokuje či použije v rámci toho zaseknutého volání, tak o tom ví a může to uklidit (neboť to leží v té proměnné tam o pár řádek výše a "stačí" implementovat něco jako finally).
Pokud je to "o pár řádků výš", tak to je relativně jednoduchá situace, ale zdaleka ne vždy to tak je. Ta alokace může být v úplně jiné funkci - a dokonce v úplně jiném driveru nebo jiné části kódu. Co hůř, za uvolnění může být zodpovědný někdo jiný, než kdo tu paměť alokoval.
Nejde ani tak o technické detaily
Jde o technické detaily. Vy a pan "nemam" máte svou představu, jak by měly věci vypadat, ale ta vychází z neznalosti toho, jak to všechno funguje uvnitř. A na základě té své představy vynášíte kategorické soudy o tom, jak je to všechno špatně navržené.
Tiskni
Sdílej: