Muzete si udelat vice profilu a pak pouzit parametr –no-remote.
Vytvorite si nejake profily:
$firefox -ProfileManager
Spustite jej jako extra instanci:
$firefox -P jmeno_profilu –no-remote
Vice instanci od jednoho profilu bohuzel pustit nelze, jsou problemy s paralelnim pristupem do databazi a podobne.
FF je three-threadovy. Tzn. proces FF tvori tri thready:
- Main thread – dela vsechnu praci a smi alokovat pamet a cist ze socketu
- UI thread – kresli na obrazovku
- JS thread – spidermonkey intepreter
- pak jsou tam jeste dalsi „servisni“ vlakna ale ta vlastne nic nedelaji.
Napr. Main thread posle http request do TCP socketu a pozada servisni vlakno aby cekalo v pollu. V okamziku kdy prijde odpoved, tak servisni vlakno posle zpravu do fronty Main threadu a ten uz pak nacte data do bufferu, preparsuje, …
Servisni thread nesmi cist ze socketu, nesmi alokovat pamet ani nesmi zapisovat do sdilenych bufferu. Pokud zrovna Main thread zaloval funkci implementovanou v JS a ceka na JSthread tak doba mezi navratem z pollu a volanim read muze byt velice dlouha. Takhle to alespon fungovalo na FF2.x. Cela tahle tragedie se jmenuje XPCOM.
To ano, ale vetsinu prace dela ten Main thread – parsovani HTML,XML,rendering,…
Main thread taky vykonava metody rozhrani vytvorene v C++. Rozhrani implementovana v JS jsou vykonavana v JS threadu – pokud ale JS thread neco dela, tak na nej vetsinou Main thread ceka. V terminologii Mozilly se tomu rika sychronni XPROXY volani. Misto toho abych zavolal nejakou metodu primo, tak vlozim pozadavek do fronty jineho vlakna a cekam na odpoved a nic nedelam. Sance ze by nejednou bezelo vice vlaken je minimalni. Takhle to alespon bylo na FF2, dneska uz je to mozna lepsi. Porad ale ten samy JS thread vykovava kod z HTML stranek i vykonava metody rozhrani implementovane v JS.