Mozilla lavora al Firefox multiprocesso

Inaugurato un nuovo progetto che avrÓ il compito di rendere il panda rosso pi¨ simile a Chrome. Ogni scheda avrÓ il suo processo. A tutto vantaggio di stabilitÓ e sicurezza

Roma - Dopo mesi di preparativi, Mozilla ha avviato un progetto il cui compito sarà quello di aggiungere a Firefox un'architettura multiprocesso, simile a quella alla base di Chrome e Internet Explorer 8. Il progetto è stato battezzato Electrolysis e il suo completamento richiederà probabilmente due anni. O anche di più.

Gli sviluppatori hanno spiegato che far girare ogni scheda (tab) o componente (motore di rendering, interfaccia utente ecc) in un processo separato non solo fornisce un maggior livello di sicurezza, ad esempio contro gli attacchi cross-site scripting, ma fa anche sì che il crash di un'istanza del browser non causi la chiusura a catena delle altre web application. Una simile caratteristica dovrebbe portare benefici anche alle performance, rendendo possibile una migliore ottimizzazione delle risorse (la memoria RAM può essere gestita in modo più dinamico ed efficiente) e un miglior supporto ai sistemi multicore.

Come spiegato in questo approfondimento di Ars Technica, implementare in Firefox il supporto multiprocesso non sarà cosa semplice: i suoi sviluppatori saranno infatti costretti a riprogettare diversi elementi chiave dell'infrastruttura del browser, utilizzando l'IPC (InterProcess Communication) per far comunicare ciascuna scheda di Firefox con i componenti condivisi (come il motore di rendering). ╚ per questo motivo che il progetto Electrolysis sarà suddiviso in quattro fasi distinte, ciascuna con una propria roadmap e dei propri obiettivi: le prime fasi si occuperanno di implementare in Firefox un supporto base al multiprocesso, mentre le altre introdurranno una granularità ancor più elevata, facendo girare in processi separati non soltanto le schede, ma anche i singoli contenuti del browser.
Un primo esempio di questo approccio è stato illustrato in questo screencast (in formato OGG Theora), dove viene mostrato un prototipo di browser che esegue il rendering delle pagine web in processi separati e isolati da quello principale. Maggiori informazioni su questa dimostrazione vengono fornite in questo post.

Negli scorsi giorni Mozilla ha anche annunciato la Open Web Tools Directory, un indice di tutti gli strumenti e le applicazioni destinati agli sviluppatori. La cosa interessante è che il nuovo repository di Mozilla arriva in due versioni: una in HTML standard e l'altra in HTML5. Quest'ultima è graficamente più complessa e attraente, ma può essere visualizzata solo sulle più recenti versioni di Safari, Chrome, Opera e Firefox.
129 Commenti alla Notizia Mozilla lavora al Firefox multiprocesso
Ordina
  • Date un'occhiata a questa tabella di compatibilità:
    i vincitori paiono essere Chrome e Safari...

    http://www.quirksmode.org/dom/w3c_html.html
    non+autenticato
  • - Scritto da: Obama
    > Date un'occhiata a questa tabella di
    > compatibilità:
    > i vincitori paiono essere Chrome e Safari...
    >
    > http://www.quirksmode.org/dom/w3c_html.html

    Tu che browser usi ?
    -ToM-
    4532
  • Non c'è nulla di HTML5... Il documento è in HTML4.1, basta leggere la source. ╚ scritto tutto in javascript... E si vede benissimo con FF 3.0.x, non ho avuto il tempo di provare altri browser.
    non+autenticato
  • - Scritto da: Utente non registrato
    > Non c'è nulla di HTML5... Il documento è in
    > HTML4.1, basta leggere la source. ╚ scritto tutto
    > in javascript... E si vede benissimo con FF
    > 3.0.x, non ho avuto il tempo di provare altri
    > browser.

    Se anzichè fermarti alla prima riga di codice scendevi un po' più giù ti accorgevi che è presente il tag canvas.

    La DTD lascia un po' il tempo che trova...

    Poi non capisco perchè non dovrebbe funzionare con FF 3.0.xPerplesso
    Uby
    893
  • Perché il 3.0.x non supporta l'HTML5
    non+autenticato
  • - Scritto da: Utente non registrato
    > Perché il 3.0.x non supporta l'HTML5

    Si, ha solo un supporto parziale, non supporta i tag audio e video, per esempio, mentre supporta i tag canvas.
    Uby
    893
  • Firefox l'avrà fra 2 anni? Un po' troppo tardi!
    non+autenticato
  • Dal 20 marzo, quand'è uscito, è passata una vita? Beh, e Google Chrome, che è da quando uscito che ha questa funzione? Comunque concordo che due anni è veramente troppo... Anche se son sicuro che migliorerà di molto le prestazioni, soprattutto sui multicore.
    non+autenticato
  • Concordo che 2 anni sono troppo e, effettivamente IE8 è da sempre multiprocess.
    Solo che IE8 è nato ufficialmente a marzo 2009 (la prima beta pubblica un anno prima), quindi appena 4 mesi. E comunque si pianta multiprocess (mi capita piuttosto spesso).
  • Da una vita?? Ma se IE8 è uscito a marzo 2009!?

    Comunque, quale sarebbe l'utilità dei processi separati su IE?

    Pessima gestione della RAM
    http://dotnetperls.com/chrome-memory

    Falle aperte
    http://secunia.com/advisories/product/21625/
    http://secunia.com/advisories/35683/


    ?????
  • si spera che si proceda a tappe, quindi rilasciado qualcosa prima... (?)
    non+autenticato
  • Certo che se 4 mesi ti semprano una vita... Rotola dal ridere
  • - Scritto da: advange
    > Certo che se 4 mesi ti semprano una vita...
    > Rotola dal ridere

    Se fosse stato il contrario, ossia ff avesse avuto il multiprocess da 4 mesi e ie no, non solo avreste detto che lo ha da una vita ma da un'eternità.
    non+autenticato
  • - Scritto da: Closed is Better
    > Se fosse stato il contrario, ossia ff avesse
    > avuto il multiprocess da 4 mesi e ie no, non solo
    > avreste detto che lo ha da una vita ma da
    > un'eternità.

    Ma ti leggi? Se mio nonno aveva le ruote era una cariola.
    non+autenticato
  • - Scritto da: caua
    >
    > Ma ti leggi? Se mio nonno aveva le ruote era una
    > cariola.

    Davvero? Mi dispiace tanto per tuo nonno.
    non+autenticato
  • E perchè? Non le aveva le ruote...
    non+autenticato
  • - Scritto da: caua
    > E perchè? Non le aveva le ruote...

    Sorride
    non+autenticato
  • Una volta i threads non esistevano e si andava a colpi di fork ed exec.
    Poi qualcuno ebbe l' idea di far girare piu processi nello stesso spazio di indirizzamento per evitare la pesantenza del fork/exec e rispamiare un po di memoria.
    Ma esiste un punto debole; poichè questi thread condividono lo stessi spazio di indirizzamento un errore in uno di essi puo far crollare tutto il sistema (il processo di cui fanno parte i thread).

    Effettivamente, nel caso in cui non sorga l' esigenza
    di performance e/o memoria il ritorno al vecchio metodo di fork/exec puo essere salutare.
    non+autenticato
  • L'articolo non è specifico da questo punto di vista, ma mi sembra lasci intendere che separeranno i processi in modo che il crash di una tab non comporti la chiusura delle altre, di conseguenza processi che non condividono spazi di indirizzamento...
    non+autenticato
  • - Scritto da: th3darkang3 l
    > L'articolo non è specifico da questo punto di
    > vista,
    Gli sviluppatori hanno spiegato che far girare ogni scheda (tab) o componente (motore di rendering, interfaccia utente ecc) in un processo separato ...
    Questa frase è presa dall' articolo, quindi non capisco la tua affermazione.




    > ma mi sembra lasci intendere che
    > separeranno i processi in modo che il crash di
    > una tab non comporti la chiusura delle altre, di
    > conseguenza processi che non condividono spazi di
    > indirizzamento...

    Per precisazione:
    nei sistemi operativi moderni per desktop e server
    i processi non condividono lo spazio di indirizzamento a meno di usare chiamate IPC fornite dal kernel.
    non+autenticato
  • e pensare che per anni hanno sparato a zero su unix perchè non supportava nativamente i thread

    e adesso invece tutto corrono verso l'unix-idea e cioè il forkA bocca aperta
  • - Scritto da: pabloski
    > e pensare che per anni hanno sparato a zero su
    > unix perchè non supportava nativamente i
    > thread
    >
    > e adesso invece tutto corrono verso l'unix-idea e
    > cioè il fork
    >A bocca aperta

    Bleah mi viene da vomitare! Fork, Exec???? Ma siamo ancora nel paleozoico qua!
    Se non sapete usare i thread a dovere non li usate e punto! Ma per piacere non venite a dirmi che quegli orrori del passato siano meglio...

    D'altra parte la programmazione multithreading spinta è una delle poche cose che distingue ancora un vero programmatore da uno zappatore. Chiunque non ha un'idea di cosa sia la sincronizzazione o non sa usare critical section, mutex, semafori, ecc.. farebbe meglio a cambiare mestiere per quanto mi riguarda.
    non+autenticato
  • trollate a parte... nei grandi e medi progetti ai quali oltretutto lavorano team di persone non riesci mai a prevedere tutte le possibili istanze di esecuzione, quindi prima o poi crashera e si portera dietro tutto...

    :)A bocca aperta
    non+autenticato
  • - Scritto da: Closed is Better

    > Bleah mi viene da vomitare! Fork, Exec???? Ma
    > siamo ancora nel paleozoico
    > qua!

    Certo, se usi windows vai con CreateProcessSorride

    > Se non sapete usare i thread a dovere non li
    > usate e punto! Ma per piacere non venite a dirmi
    > che quegli orrori del passato siano
    > meglio...

    Non esiste il meglio o peggio in questo caso,dipende dalle esigenze.
    La programmazione a thread è piu complessa di quella classica a processi, e perchè complicarsi la vita se non è indispensabile ?


    >
    > D'altra parte la programmazione multithreading
    > spinta è una delle poche cose che distingue
    > ancora un vero programmatore da uno zappatore.

    Mi sa che il mondo è pieno di zappatori (piccola battuta)

    > Chiunque non ha un'idea di cosa sia la
    > sincronizzazione o non sa usare critical section,
    > mutex, semafori, ecc.. farebbe meglio a cambiare
    > mestiere per quanto mi
    > riguarda.

    Esistono tante attivita nell' informatica dove non servono oggetti di sincronizzazione ,creazione di processi e thread.
    non+autenticato
  • - Scritto da: vintage
    > - Scritto da: Closed is Better
    >
    > > Bleah mi viene da vomitare! Fork, Exec???? Ma
    > > siamo ancora nel paleozoico
    > > qua!
    >
    > Certo, se usi windows vai con CreateProcessSorride
    >
    > > Se non sapete usare i thread a dovere non li
    > > usate e punto! Ma per piacere non venite a dirmi
    > > che quegli orrori del passato siano
    > > meglio...
    >
    > Non esiste il meglio o peggio in questo
    > caso,dipende dalle
    > esigenze.
    > La programmazione a thread è piu complessa di
    > quella classica a processi, e perchè complicarsi
    > la vita se non è indispensabile ?
    >
    >
    >
    > >
    > > D'altra parte la programmazione multithreading
    > > spinta è una delle poche cose che distingue
    > > ancora un vero programmatore da uno zappatore.
    >
    > Mi sa che il mondo è pieno di zappatori (piccola
    > battuta)
    >
    > > Chiunque non ha un'idea di cosa sia la
    > > sincronizzazione o non sa usare critical
    > section,
    > > mutex, semafori, ecc.. farebbe meglio a cambiare
    > > mestiere per quanto mi
    > > riguarda.
    >
    > Esistono tante attivita nell' informatica dove
    > non servono oggetti di sincronizzazione
    > ,creazione di processi e
    > thread.

    Senza dubbio non è sempre indispensabile ma credo che ormai siano pochi i progetti dove se ne possa fare a meno. Anche se fosse solo per evitare il banale blocco dell'interfaccia per operazioni che richiedono qualche secondo io trovo l'uso dei thread fondamentale per dare un'idea di "serietà" al prodotto. E un programmatore che non conosce queste problematiche non può certo definirsi un programmatore ed è molto più facile che faccia danni anche in scenari non multithread... IMHO ovviamente.
    non+autenticato
  • - Scritto da: Closed is Better

    > Senza dubbio non è sempre indispensabile ma credo
    > che ormai siano pochi i progetti dove se ne possa
    > fare a meno. Anche se fosse solo per evitare il
    > banale blocco dell'interfaccia per operazioni che
    > richiedono qualche secondo io trovo l'uso dei
    > thread fondamentale per dare un'idea di "serietà"
    > al prodotto. E un programmatore che non conosce
    > queste problematiche non può certo definirsi un
    > programmatore ed è molto più facile che faccia
    > danni anche in scenari non multithread... IMHO
    > ovviamente.
    Ok , detto cosi posso anche essere d' accordo , ma eri partito sparato a inneggiare contro fork/exec come un fondamentalista ..
    non+autenticato
  • - Scritto da: Closed is Better

    > Senza dubbio non è sempre indispensabile ma credo
    > che ormai siano pochi i progetti dove se ne possa
    > fare a meno. Anche se fosse solo per evitare il
    > banale blocco dell'interfaccia per operazioni che
    > richiedono qualche secondo io trovo l'uso dei
    > thread fondamentale per dare un'idea di "serietà"
    > al prodotto.

    Non e` obbligatorio usare il multithreading per queste cose. Va benissimo anche il multiprocessing (sì, quello con fork e exec).

    Vantaggio dei thread: velocità in alcuni casi
    Svantaggio dei thread: devi stare MOLTO attento alla sincronizzazione, altrimenti muoiono entrambi i thread. Sono "fragili".

    Vantaggio dei processi: è più semplice sincronizzarli e passare dati. Se crasha un processo l'altro continua a lavorare. Un processo non può toccare la memoria di un altro.
    Svantaggio dei processi: leggermente più lenti in alcuni casi.

    Bye.
    Shu
    1232
  • - Scritto da: Closed is Better
    > - Scritto da: pabloski
    > > e pensare che per anni hanno sparato a zero su
    > > unix perchè non supportava nativamente i
    > > thread
    > >
    > > e adesso invece tutto corrono verso l'unix-idea
    > e
    > > cioè il fork
    > >A bocca aperta
    >
    > Bleah mi viene da vomitare! Fork, Exec???? Ma
    > siamo ancora nel paleozoico qua!

    Sarà il paleozoico, ma è così che fanno quelli di Chrome e pure quelli di IE8: isolano le tab dentro a processi. Questi processi poi fanno uso di thread per il rendering ma solo incapsulando in processi si evita che un thread impazzito vada a tirar giù tutto il browser e non una singola tab.
    non+autenticato
  • Ma perché? Per me, è solo un visualizzatore... Direi quasi come un magazine settimanale Sorride
    non+autenticato
  • Beh per quelli che li sviluppano ce tutto un business dietro... per noi le cose migliorano con l'accrescere di funzionalità (comodita..), e con il fatto che si spera diventino sempre piu leggeri in modo da poter fare mille cose contemporaneamente senza rallentamenti...Sorride
    non+autenticato
  • Ci sono settimanali di un certo livello e settimanali spazzatura. Idem per i browser, anche se quasi tutti i browser sono buoni, basta che non inizino con la I Sorride
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 12 discussioni)