Thread model se používal na VMS, a používá se i na unixech (viz Oracle, Apache, a dnes v podstatě už cokoliv). Thready jsou totiž poněkud hubenější, než procesy, a výsledek tedy má daleko lepší scalability. Výjimka není problém - problém je případná memory corruption (které se ovšem nevyhnete ani v process modelu, protože nějak data mezi procesy sdílet musíte - typicky přes shared memory).
Záleží na kvalitě implementace procesů a Linux dokazuje, že procesy mohou být i rychlé. Problém není v odladěných aplikacích typu Apache, nebo SQL server, problémy jsou v podnikových (zákaznických) aplikacích, které píší žabaři, a tam je rozdíl ve výkonu minimální, neb stejně nevytěžují procesor a rozdíl ve spolehlivosti maximální neb pád threadu může sestřelit celý proces - celý server. Šance, že se Vám tak stane jsou v process modelu nižší, už jen proto, že přístup do shared memory je exkluzivní a používá se jen ve výjimečných případech, jinak se používá pipe a další bezpečné komunikační kanály. Navíc pokud už máte problém s corrupted shared memory, lze tento stav poměrně přesně identifikovat, a aplikaci slušně ukončit neb přesně víte, který segment paměti mohl být zasažen a který nikoliv. Důvod, proč se také používají thready je relativní pomalost vytváření nových procesů v NT, a pomalá shared memory. Tudíž aplikace, které chtějí nějak běžet na NT musí chca nechca tento model použít - není totiž na výběr. Nejsem proti managed jazykům, .NET jsem používal už před sedmi roky a vůči VBScriptu, Visual Basicu je to super vývojový nástroj a jestli jej budou umět programátoři použít, tak jen jedině dobře. Na druhou stranu znám natolik proces vývoje sw, že si dovolím pochybovat, že by se díky .NETu něco výrazněji změnilo, kromě hw. nároků. Zdroje chyb jsou v komplexnosti sw, v roztříštěnosti vývojových týmů, v architektuře, zejména v architektuře a pak ještě v lidech.
