Threads x procesy

[martin.kula na deltaes.cz]

On Thu, 11 Oct 2001, Michal Dobes wrote:

> > Mozne reseni je obsluha sekvencne jednim procesem nebo soucasna obsluha
> > ....
> 
> Resim neco podobneho, akorat ta doba je takova, ze mam rucit za to, ze
> to
> 8 let nezdechne.

Tak nejak ;-))))))

> 
> > Pro druhy pripad mam nasledujici dilema:
> > pozit fork a 1-mnoho stejnych procesu nebo threads.
> 
> Jestli pouzijete fork nebo thready je na vas, ale doporucuji
> spustit maximalni pocet pripustnych treadu/uloh hned pri startu
> a predavat jim jen pozadavky k vyrizeni a jinak necht cekaji,
> protoze pokud budete vtvaret a likvidovat procesy podle prichozich
> pozadavku, tak po nejake dobe se to pravdepodobne zacne pokladat
> na nechutnosti typu VM: tryng free pages (ci jak to presne zni),
> zvlaste v pripade, ze vyuzivate dostupnou pamet celkem na doraz
> a 99% vykonu CPU to travi v real time casti (po nekolika tydnech
> behu uplynulo v linuxu nekolik minut).
> 
> Nejlepe si je vse hned pri startu spustit a naalokovat staticky,
> vcetne veskere pameti a delat si v ni vlastni rizeni.

Jo s tim pocitam

> Aspon s kernelem 2.2.19+RT Linux 3.1.

Ja to nemam tak uplne RT a navic jsem nucen pozivat jadra rady 2.4.x
(pravdepodobne 2.4.10-acX) takze jsem se RTlinuxu zatim nepoohlizel ;-)

> Zatim to ve svem vidim na thready: jeden obsluhuje data tekouci
> z RT casti, dalsi dela spravu pameti, treti vyrizuje komunikaci
> pres RPC-XML a posledni signalizacni komunikaci pres UDP.
> 
> Pri pouziti vicero procesu se clovek musi strasit se sdilenou
> pameti pres IPC, coz muze byt zdroj problemu.

Bohuzel tomu se nevyhnu protoze tam pobezi jeste procesy
(asynchronne) ktere budou muset s daty taky pracovat ;-(

> 
> Dalsi vyhodou pri doprednem spusteni a naalokovani vseho je 
> rychlejsi odezva. Ale to zalezi na vasi aplikaci.
> 
Right ;-)

Dik

Martin