Internet Explorer 9 è vecchio, lo dice Mozilla. Microsoft risponde

Segnalo che su IE9 per verificare se la Modalità Protetta è attiva o no è necessario premere il tasto destro sulla pagina Web e selezionare Proprietà.
È scritto all'interno del pannello Proprietà, mentre su IE8/7 era scritto in basso nella status bar.

Ciao,
il maggior overhead della scelta di chrome di gestire i tab come processi separata è una cosa citata spesso ma è abbastanza inesatta.

Il punto è che, dato che ogni sistema operativo moderno condivide la sezione TEXT (il codice dell'eseguibile) tra i vari processi relativi a un determinato eseguibile, l'overhead è in realtà minimo.

Riporto dei test fatti da me ormai quasi un anno fa:



Quindi, qualunque rilevazione sull'uso di memoria che non tenga conto della condivisione delle sezioni TEXT è assolutamente inaffidabile. In realtà, l'articolo di DinoxPC è abbastanza interessante perchè il task manager, di default, fa vedere solo l'area di memoria PRIVATE e quindi esclude automaticamente l'area TEXT dalla comparazione. E infatti dall'articolo si vede che Opera e IE, due browser che non fanno uso di un processo per tab, hanno un consumo di memoria superiore a Chrome; quindi è palese che non è l'equazione un tab = un processo a comportare automaticamente un grosso uso della RAM.

Ciao.

Puntualizzo solo che IE8 sin dalle prime beta, prima di Google Chrome (che poi però ha fatto prima a rilasciare una release ufficiale), usa processi separati. La frase sopra era valida per IE7.

Vero, avevo letto male il riferimento sull'articolo di DinoxPC.
Comunque il discorso sulla presunta pesantezza dei processi rimane valido, basta vedere il confronto con Opera (che pur usando un solo processo consuma più memoria).

Ciao.

L'overhead non è dovuto al fatto di non condividere la sezione di codice fra i vari processi, se fosse così per avviare un'applicazione bisognerebbe ricaricare tutte le librerie ogni volta.
Piuttosto l'overhead viene fuori dal fatto che obblighi il sistema operativo a gestire più processi, con tutte le strutture dati associate al seguito, in più hai necessità, qualora tu voglia far comunicare due processi, di utilizzare delle trap al kernel che sono pezzi di codice costosi da eseguire perchè modificano lo stato della cpu da user mode a privileged mode.

Ma queste non sono cose che dico io, stanno scritte in qualunque libro di sistemi operativi e penso che probabilmente sto fraintendendo io e che tu le hai già lette, però vale la pena chiarire questo aspetto.

I thread comunque li hanno inventati appositamente per azzerare l'overhead, visto che lo spazio di indirizzamento è condiviso e ogni thread può accedere ai dati degli altri (che è anche il motivo per cui se crasha un thread crasha tutto il processo).




IE 8 fa uso di un processo per tab, hexaee lo ha segnalato in precedenza.
Comunque il task manager mi pare di ricordare che mostrasse il working set e credo di esserne abbastanza sicuro visto che quando lanciavo un processo abbastanza corpulento, vedevo proprio il sistema operativo che paginava i processi riducendo a mano a mano il loro working set.

ODDIO!!

Evito commenti pieni di insulti o ci sarebbe da scrivere un paragrafo.

Ma quelli di Mozilla misa lavorano in Jamaica.
Prima di dire certe cose, provate i browser, non basatevi su test fatti da altri. Inoltre posso confermare che il sito html5test sia assolutamente fasullo e truccato, poiché non offre un punteggio equo in termini di prestazioni.
Potete vedere infatti come i plugin MPEG-4, Ogg e WebM non supportati dal browser danneggino di oltre 10 punti il risultato finale. Questo è assolutamente vergognoso dato che il non supporto all'H.264 dovrebbe essere penalizzato invece. Inutile commentare le altre funzioni, un webmaster come me sa a cosa mi riferisco. Non sto difendendo IE9, sto attaccando Mozilla comunque...

Ciao,
nessuno mette in dubbio che i threads abbiano vantaggi di snellezza e velocità rispetto ai processi, dovuti alla condivisione della stessa area di memoria RAM.

Il punto è che l'overhead di un processo rispetto a un thread è generalmente nell'ordine dei 4-16 KB di RAM (per stack e altre cose). Questo significa che, nel contesto di un browser, stiamo parlando di un'overhead molto limitato: con 1000 schede aperte, sarebbero circa 4-16 MB. Insomma: in questo contesto, l'overhead sulla RAM è pari a zero.

L'impossibilità di non aver accesso alla stessa area di memoria ma essere costretti a usare l'IPC (cosa non vera in assoluto, comunque) è anch'esso un problema che non si applica in questo contesto, in quanto le varie tab _non_ devono parlarsi (e se scambiano dati, lo faranno in maniera molto ridotta).

L'uso di threads rispetto ai processi porta dei vantaggi prestazionali concreti quando parli di migliaia di processi e una notevole mole di dati da scambiare. Esempio: in passato apache creata un nuovo processo per ogni connessione. Capisci quindi che, in caso di web server molto visitati, questo rappresentava un problema (magari l'overhead del solo stack, 4 KB, era più grande della dimensione dell'HTML da mostrare).
Altro esempio: con la libreria PThread, puoi aprire migliaia di threads in pochi secondi e con un overhead minimo; il forking in questo caso sarebbe molto più lento.

Comunque, siamo in un campo completamente diverso rispetto a quello dei browser.



Vero su IE8, è che nella mia mente ero rimasto al 7
Il task manager di Vista / 7 visualizza, di default, il working set _privato_ che è proprio l'area di memoria privata usata dal processo attualmente attiva. E' per questo che dico che la comparazione di DinoxPC è interessante: avendo automaticamente (e forse inconsapevolmente) escluso dalla comparazione l'area TEXT (il codice vero e proprio), nell'articolo viene misurata la quantità di memoria privata (cioè sostanzialmente dati) impiegata dai vari browser. E si vede chiaramente che Opera, per quanto monoprocesso, usa più memoria di Chrome.

Ribadisco il concetto: se parliamo di uso di memoria in ambito browser, la differenza (per quanto misurabile) non la fa l'uso di processi rispetto a threads, ma tanti altri fattori, a volte conosciuti solo agli sviluppatori.

Ciao.

ma nessuno di voi a mai sviluppato un sito con IE? Qualsiasi versione essa sia..
Non è vecchio o nuovo.. E' da non usare.

Non sono del tutto d'accordo. Sull'overhead di un processo, non ho idea attualmente quante risorse siano destinate da un moderno sistema operativo ad ogni processo. Di sicuro lo stack ce l'hanno anche i thread, che oggigiorno sono le entità schedulabili e quindi hanno il loro bravo stack.

Per lo scambio di dati, immagina di aprire una, due o più tab che puntano a pagine con le stesse risorse (per esempio il forum). Non so se chrome gestisca la cosa, ma caricare in memoria tante istanze dello stesso elemento non è una bella cosa. Certo, puoi utilizzare la memoria condivisa che è una bella cosa, ma ti serve sempre un processo centralizzato che la gestisce, e quindi altro IPC e se va' in crash lui vanno in crash tutti quanti lo stesso.



Eh però pthreads è un po' un terreno minato, visto che in base all'implementazione gestisce thread di livello utente e thread di livello kernel.

Comunque si, il fork è sempre più costoso, anche se apache aveva una gestione un po' diversa: il processo non terminava al termine della connessione, ma veniva mantenuto attivo per un tot di connessioni, poi veniva terminato e rinnovato per evitare leaks e per evitare costosi fork. Questo almeno nelle ultime incarnazioni della versione 1.x prefork.



Non conosco la definizione di working set privato, però hai ragione riguardo al fatto che come il browser usa la memoria è conosciuto solo agli sviluppatori. Magari uno utilizza una cache per oggetti di un certo tipo che l'altro non usa, e così via...

figo, siete arrivati a parlare di thread, pthread e fork

a quando la discussione tra control unit microprogrammata e hardwired ?

cmq black, i thread hanno nel loro definitore, l'id del thread, uno stack e la copia dei registri compreso program counter

ogni pcb ha l'elenco dei thread che gli appartengono

a scuola ci hanno fatto un disegnino esplicativo se mi viene lo metto poi ma è abb. ot