Ladeni multithreadove aplikace

[Mikulas Patocka]

>> Mne pripada, ze fork je jedna z nejhorsich chyb, jake navrhari unixu
>> udelali. Clovek si nemuze pustit podproces, aniz by si nezprasil celou
>> page table a aniz by nebyl terorizovan spoustou cow page faultu.
>
>Pokud se vam nejak moc stranek kopiruje kvuli zapisu, tak mate
>spatne udelanou aplikaci.

No a co kdyz velky proces, ktery bude mit namapovano treba 512M
virtualni pameti bude chtit pustit maly podproces? Tak se pri fork()
512k dat z page table zkopiruje do noveho procesu a vzapeti se zahodi
pri exec(). To kopirovani pagetable je uplne zbytecne.

Pak se delaji takove prasarny jako BSD vfork...

>Lze vyjit z pomerne dobre empiricky overeneho pravidla, ze (at uz v
>multithreaded nebo fork()ujici aplikace) pracovnich dat, do nichz se
>zapisuje, se sdili jen pomerne malo (treba vzhledem k velikosti
>stacku, ktery musite vytvorit i v m-t pripade). Velka cast dat (a kod
>apod.) se "sdili" jen pro cteni...

Pri threadech vsak k zadnemu kopirovani page tablu ani k cow
nedochazi. Proto budou thready porad rychlejsi, nez dobre udelane
forkovani.

>> Docela by me zajimalo, jak mohl unix chodit na strojich bez
>> strankovani, kde se cely proces musel kopirovat.
>
>Proste tak, ze se fork()ujici aplikace napsala dobre. Zapisy jsou jen
>do par presne lokalizovanych mist, a ne rozesete po cele pameti.

Pokud to nemelo stranky, tak jediny mozny zpusob implementace forku
byl zkopirovat fyzicky celou pamet procesu - a to je hrozne pomale.

Mikulas