Když není problém efektivity Linux kernelu se zapnutou preempcí ve statických strukturách, tak kde tedy? Píšete, že tomu vůbec nerozumím. To je sice roztomilé, ale bylo by lepší, kdybyste problematiku vysvětlil.
"Výmysly" u forku: co je špatně, a jak to podle vás je? K rozdílu mezi vytváření vlákna a procesu: pokud máte server, který obsluhuje requesty, tak jich budete chtít obsluhovat více najednou. Nejprve se zpracovával pouze jeden požadavek, později se přišlo s worker procesy, a nevyšším stupněm vývoje jsou zatím thready. Mají totiž nejnižší režii. Přepínání kontextů: co je konkrétně špatně? Přepnutí kontextu procesu a vlákna možná trvá stejně dlouho na Linuxu (do jeho vnitřností tolik nevidím), ale ne tak v jiných systémech. Kontext switch mezi procesy opravdu znamená nutnost natáhnout memory map procesu (page-mapping table). Nevidím důvod, proč byste totéž dělal při změně kontextu mezi thready, které v rámci procesu memory map sdílí. Dále k forku: bohužel forkované procesy spolu "mluví" jen přes IPC, což je opět overhead navíc. Jestli měl Multics thready, to nevím, ale řada systémů (včetně VMS, Windows, Solarisu a Windows) má jejich implementaci dost kvalitní. Nakonec thready se prosazují i na Linuxu, jenom to dlouho trvalo (viz katastrofa jménem Linuxthreads).
Názor k článku
Linspire a Microsoft: Další dva kamarádi
