Threads x procesy

[Michal Dobes]

martin.kula na deltaes.cz wrote:
> Program na hw s omezenou pameti a bez swapu (bez hd), ktery navaze TCP
> spojeni s 1 - mnoha zarizenimi a tyto spojeni drzi permanentne po dobu
> hodin, dnu, tydnu ..... pripadne data tekouci z/k zarizenim jsou
> ukladany/cteny do/ze shared memory.
> 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.

> 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.
Aspon s kernelem 2.2.19+RT Linux 3.1.
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.

Dalsi vyhodou pri doprednem spusteni a naalokovani vseho je 
rychlejsi odezva. Ale to zalezi na vasi aplikaci.

	Majkl