Oddělení procesů stojí celkem dost prostředků. Takový context switch není zdaleka zdarma, a kernel mode transition je ještě dražší. Popisoval jsem tu v jiném příspěvku alternativní způsob oddělení procesů (SIP), a dával tam linky. Podstata je ale v tom, že řešit nastalý problém je v podstatě k ničemu, protože mléko je už rozlité. Pokud například jazyk neumožní pointerovou aritmetiku (a pointery na funkce zapouzdří tak, aby s nimi nešlo manipulovat), odstraní se příčina řady chyb. Viz též co jsem psal o statické analýze kódu (například záruka typu "kód oneobsahuje deadlock").
Ano, preemptivní (za běhu kódu můžeme utrhnout execution a provést context switch) a reentrantní (kód lze provádět na více místech najednou) kernel. Mluvím o přepnutí kontextu ve chvíli, kdy se thread (proces) nachází v režimu jádra. Samozřejmě pokud kernel není preemptivní, zvyšuje se lacency. Pokud není reentrantní, je to problém při SMP (scalability velmi trpí). Samozřejmě preemptivní a reentrantní kernel nesmí držet statická data, a kde je to nutné (jako že takových míst je dost), musí se použít nějaký mutex. Když se tak postupuje od návrhu, je to celkem v pohodě. Pokud se preempce kernelu implementuje dodatečně, zavání to hromadou bugů (viz Linux kernel s CONFIG_PREEMPT), a mizerným výkonem (opět viz Linux; nevyznám se v Linx kernelu, ale zřejmě by to chtělo snížit míru používání statických dat, což se dodatečně bude dělat velmi špatně).
ACID FS nesouvisí s DB. DB jsem použil pouze pro demonstraci možností. Jiným použitím je, když zahájím transakci, na webový server budu pět minut kopírovat novou verzi aplikace, a pak dám comit. Nejprve budou všecny soubory ve staré verzi, a po commitu v nové verzi. Možností použití transakcí je celá řada.
Odpověď na názor
Odpovídáte na názor k článku Linspire a Microsoft: Další dva kamarádi.
Pravidla pro diskutující
Přidáním čtenářského příspěvku do diskusí či fóra souhlasíte s tím, že budete dodržovat následující pravidla. Při jejich hrubém porušení se vystavujete riziku smazání příspěvku, jeho modifikaci, v krajním případě i zablokování přístupu do diskusí.
Redakce ze zásady nezasahuje do čtenářských diskusí a zavazuje se, že nebude mazat ani modifikovat příspěvky, kromě případů, kdy tyto porušují některé z následujících pravidel. V takové situaci je na zvážení redakce, zda příspěvek modifikuje s viditelným upozorněním, či přímo smaže. Redakce nikdy nemaže „nesouhlasné komentáře“ jen proto, že jsou nesouhlasné. Vítáme střet názorů, ale vždy v rámci slušné a kultivované debaty.
Příspěvky nesmí obsahovat:
- Vulgární či hrubé výrazy.
- Urážlivé výroky na adresu druhé osoby či skupiny osob.
- Texty, které mají za cíl jen vyprovokovat emotivní reakci (trolling).
- Rasové útoky či útoky na jakoukoliv jinou menšinu či skupinu obyvatel.
- Komerční nabídky a affiliate odkazy.
- Odkazy na warez, sériová čísla, licenční kódy, pornografii a další nevhodný materiál stejně jako žádosti o poskytnutí tohoto obsahu.
- Prokazatelně protiprávní obsah.
Informace o soukromí: U všech přidaných komentářů provozovatel ukládá IP adresu a hostname odesílatele. U neregistrovaných uživatelů se na webu zobrazuje část hostname, případně IP adresy, neumožňující identifikovat konkrétní počítač.
Povolené značky XHTML: a, br, code, em, li, ol, p, pre, strong, sub, sup, ul
