Alfonso Maruccia

Webkit2, schede separate in casa

Apple annuncia la disponibilitÓ di una nuova versione del suo celebre motore di rendering per browser. L'abilitÓ di isolare le schede in processi separati fa il suo debutto: come dentro Google Chrome

Roma - A Cupertino devono aver apprezzato parecchio una delle caratteristiche esclusive di Chrome, vale a dire la capacità di isolare ogni scheda in un singolo processo per una maggiore stabilità e sicurezza dell'esperienza di navigazione. Una capacità talmente apprezzata che Apple ha testé annunciato l'integrazione direttamente nel suo browser engine WebKit, non a caso lo stesso alla base del browser di Google.

Anche Safari come Chrome sarà dunque dotato presto dell'isolamento forzato delle singole istanze di navigazione, di modo che l'eventuale crash o malfunzionamento di una scheda non pregiudichi il funzionamento dell'intero browser.

La principale differenza tra WebKit2 e l'attuale approccio seguito da Mountain View, spiegano gli uomini Apple, è che il supporto al funzionamento multi-processo è stato ora integrato nel cuore del layout engine e farà quindi parte del corredo genetico di tutti i browser che utilizzano WebKit.
Un'altra novità di WebKit2 è l'implementazione di chiamate API (Application Program Interface) dirette verso l'engine a cui verrà inibito il "blocco" dell'attività del browser in attesa del dovuto "feedback" in memoria. Con il nuovo approccio si dovrebbero avere software (o plugin) più reattivi nell'interagire con il browser, finalmente capace di occuparsi anche d'altro mentre è impegnato a fare il rendering della pagina o in altro genere di attività.

La nuova versione di WebKit (attualmente disponibile solo nelle versioni Windows e Mac) promette migliorie a quello che è già ampiamente considerato il vincitore della guerra tecnologica tra i framework di rendering web usati dai vari browser in circolazione sul mercato. Tanta è la forza di WebKit che persino Mozilla, che nel suo Firefox implementa l'engine concorrente "Gecko", dice di voler rubare pezzetti di codice al progetto open source di Apple per migliorare l'esperienza di navigazione offerta dal Panda Rosso.

Alfonso Maruccia
Notizie collegate
19 Commenti alla Notizia Webkit2, schede separate in casa
Ordina
  • Feature già presente in IE8
    non+autenticato
  • Webkit nasce in seno alla community opensource, con lo sforzo congiunto dei team di KDE e di GNOME, non è stato creato dalla Apple.
    Così come per KHTML usato da Safari si tratta di motori nati da lavori collettivi, di cui poi ingiustamente grandi case di software si prendono il merito. Purtroppo anche grazie ad articoli scritti da persone male informate.
    non+autenticato
  • Infatti, se non sbaglio webkit era alla base del browser konqueror, di kde.

    Comunque, va benissimo che le aziende li usino, a condizione che poi rilascino i sorgenti delle eventuali modifiche (cosa che Apple ha fatto); del resto, l'idea alla base del software libero e della licenza GPL era proprio quella.
    non+autenticato
  • WebKit E' di Apple, o meglio è della nuova community di sviluppatori che ci lavorano, in arte di Apple, in parte di Google, eccetera.
    E' ovviamente vero che nasce da KHTML, ma non per questo è vero che Apple non ha lavorato pesantemente su quel codice per un anno prima di rilasciarlo open, e dopo questo passaggio il codice è senza dubbio mutato ulteriormente.

    Cioè in altre parole, non è che siccome è nato da KHTML parecchi anni fa, è ancora KHTML. Il framework si è evoluto e nel frattempo hanno sostituito parti intere, come per esempio l'engine JavaScript.
    Per cui non capisco tutto questo astio nei confronti di Apple e la conseguente voglia di sminuire a tutti i costi ciò che fa.
    non+autenticato
  • - Scritto da: RunAway

    > Cioè in altre parole, non è che siccome è nato da
    > KHTML parecchi anni fa, è ancora KHTML.

    Giusto è come dire che Internet Explorer 8 non è stato fatto da Microsoft ma da NCSA con il loro Mosaic

    http://en.wikipedia.org/wiki/Internet_Explorer#His...

    Oppure dire che Firefox non è merito della comunità open source, dato che il codice deriva dalla Netscape Corp.

    > Per cui non capisco tutto questo astio nei
    > confronti di Apple e la conseguente voglia di
    > sminuire a tutti i costi ciò che
    > fa.

    1) perchè tra i falliti/repressi è di moda e fa "cool"
    2) perché c'è gente spaventata che ha paura di perdere il lavoro (vedi punto3)
    3) perché c'è gente pagata dalla concorrenza che cerca di seminare FUD per evitare il fallimento

    La gente normale a cui non frega nulla di Apple semplicemente la ignora. Così come io ignoro Sony, Nokia, BMW, Mercedes, etc....

    Fan LinuxFan Apple
  • - Scritto da: RunAway

    > WebKit E' di Apple, o meglio è della nuova
    > community di sviluppatori che ci lavorano, in
    > arte di Apple, in parte di Google,
    > eccetera.

    Hai ragione, ma devi ammettere che scrivere "Apple annuncia la disponibilità di una nuova versione del SUO celebre motore di rendering" riferito a Webkit è fuorviante.
    Sembra che Webkit sia SOLO di Apple, cosa che non è vera, visto che hanno potuto integrare il codice di Chrome solo perché Webkit è ANCHE di Google (e anche di Gnome, e anche di KDE, ecc. ecc.).

    Basterebbe scrivere "Apple annuncia la disponibilità di una nuova versione del suo browser Safari, basato su una nuova versione di WebKit", o "Apple annuncia una nuova versione di WebKit, il motore che sarà alla base della prossima versione del suo browser Safari".

    Sarebbe comunque ambiguo, ma almeno non sarebbe falso.

    Bye.
    Shu
    1232
  • - Scritto da: Shu
    > - Scritto da: RunAway
    >
    > > WebKit E' di Apple, o meglio è della nuova
    > > community di sviluppatori che ci lavorano, in
    > > arte di Apple, in parte di Google,
    > > eccetera.
    >
    > Hai ragione, ma devi ammettere che scrivere
    > "Apple annuncia la disponibilità di una nuova
    > versione del SUO celebre motore di rendering"
    > riferito a Webkit è
    > fuorviante.

    No è innegabile che la maggior forza di sviluppo e la maggior integrazione con il suo OS venga da Apple:

    http://en.wikipedia.org/wiki/WebKit

    Studiati la storia e dimmi dove ci vedi scritto che "Google", per esempio, ha apportato contributi sostanziali al progetto almeno quanto Apple.


    > Sembra che Webkit sia SOLO di Apple, cosa che non
    > è vera, visto che hanno potuto integrare il
    > codice di Chrome solo perché Webkit è ANCHE di
    > Google (e anche di Gnome, e anche di KDE, ecc.
    > ecc.).

    WebKit non è "anche" di Google, WebKit è un progetto rilasciato "open source" da Apple a cui Google ha deciso di attingere/contribuire allo sviluppo.

    > Basterebbe scrivere ...
    > [..]
    > Sarebbe comunque ambiguo, ma almeno non sarebbe
    > falso.

    Sarebbe ambiguo e soprattutto ipocrita.

    Fan LinuxFan Apple
  • > Studiati la storia e dimmi dove ci vedi scritto
    > che "Google", per esempio, ha apportato
    > contributi sostanziali al progetto almeno quanto
    > Apple.
    >

    E' vero che Google, da quando ha rilasciato Chrome, è diventata attiva nello sviluppo di WebKit. Basta vedere il blog di Surfing Safari (http://webkit.org/blog/) dove ultimamente vengono aggiunti nuovi "reviewers" dipendenti di Google. Ma Webkit rimane sostanzialmente cosa Apple e il leader è indiscutibilmente Dave Hyatt da anni ormai dipendente Apple. (Per la cronaca Hyatt in precedenza era uno degli sviluppatori leader di Firefox).
    non+autenticato
  • > Hai ragione, ma devi ammettere che scrivere
    > "Apple annuncia la disponibilità di una nuova
    > versione del SUO celebre motore di rendering"
    > riferito a Webkit è
    > fuorviante.
    > Sembra che Webkit sia SOLO di Apple, cosa che non
    > è vera, visto che hanno potuto integrare il

    Puoi leggerti la storia su wikipedia, comunque per riassumere Webkit è un progetto partito dal codice di KHTML ma ormai finanziato da Apple, con gli sviluppatori principali Apple la maggioranza del codice Apple: dunque non c'è molto altro da dire. Certo che Webkit non è SOLO di Apple, è semplicemente un progetto open source di Apple e quindi anche altri possono aiutare/contribuire.
    non+autenticato
  • - Scritto da: Giorgio More

    > Webkit nasce in seno alla community opensource,
    > con lo sforzo congiunto dei team di KDE e di
    > GNOME, non è stato creato dalla Apple.

    Ma lo sappiamo: Apple è un contributor. Per anni è stato il più importante. Adesso il più importante è Google.

    http://neugierig.org/software/chromium/notes/2010/...
    FDG
    10933
  • Sono per caso l'unico a pensare che ogni scheda in un diverso processo sia un inutile dispendio di risorse, quando per ovviare ad eventuali blocchi basterebbe inserire nella VM che gestisce il codice ECMAScript un controllo anti-freeze (così come fa opera)?

    E se qualcuno salta su a dire che lo sviluppo multiprocesso migliora le performance è la volta buona che lo prendo a badilate sui denti; un processo per scheda causa un decadimento delle prestazioni esponenziale all'aumerntare delle schede oltre un certo valore n.
    non+autenticato
  • - Scritto da: 00101010
    > Sono per caso l'unico a pensare che ogni scheda
    > in un diverso processo sia un inutile dispendio
    > di risorse, quando per ovviare ad eventuali
    > blocchi basterebbe inserire nella VM che gestisce
    > il codice ECMAScript un controllo anti-freeze
    > (così come fa
    > opera)?
    >
    > E se qualcuno salta su a dire che lo sviluppo
    > multiprocesso migliora le performance è la volta
    > buona che lo prendo a badilate sui denti; un
    > processo per scheda causa un decadimento delle
    > prestazioni esponenziale all'aumerntare delle
    > schede oltre un certo valore
    > n.

    ma avere i processi separati non permette ad un pc multicore di gestirli meglio?
  • Più core, più thread. I processori gestiscono i thread, non i processi.
    non+autenticato
  • - Scritto da: Nedanfor non loggato

    > Più core, più thread. I processori gestiscono i
    > thread, non i
    > processi.

    E` l'esatto opposto. Le CPU gestiscono i processi, non i thread.

    Originariamente un thread veniva eseguito nello stesso processo di chi l'aveva creato, condividendone la memoria, quindi non poteva fisicamente girare su due CPU (o core) separati, perché il flush delle cache avrebbe annullato il vantaggio di avere dei thread e segato le gambe alle prestazioni.

    Oggi quasi tutti i S.O. trasformano i thread in processi, e gestiscono in modo particolare l'assegnazione delle CPU (o dei core, che sono la stessa cosa) tramite affinità per ridurre al minimo il flush delle cache.

    L'unico caso in cui i thread converrebbero sono i processori Hyperthread, che riescono a eseguire due thread nello stesso core, quindi con la stessa cache, ma anhe loro hanno bisogno di supporto dal S.O. per assegnare i thread allo stesso core del genitore e per gestire la cache.

    In pratica, con le architetture di oggi e del prossimo futuro, conviene usare processi piuttosto che thread, in qualsiasi caso.

    Bye.
    Shu
    1232
  • - Scritto da: Nedanfor non loggato

    > Più core, più thread. I processori gestiscono i
    > thread, non i processi.

    Ma dove l'hai sentita questa fesseria?
    FDG
    10933
  • - Scritto da: Nedanfor non loggato
    > Più core, più thread. I processori gestiscono i
    > thread, non i
    > processi.

    ORRORE!!!!!

    Ti consiglio di leggere (anzi studiare) il libro "I moderni sistemi operativi" del sig. Tanenbaum Andrew S.
  • - Scritto da: dariocaruso
    > ma avere i processi separati non permette ad un
    > pc multicore di gestirli
    > meglio?

    NO!

    Mi spiego un processore può gestire agilmente un software che abbia un numero di processi inferiori al numero di core; una soluzione con problemi analoghi tuttavia con minore dispendio di memoria sarebbe usare il multithreading in cui diversi thread accedono allo stesso spazio di memoria.
    non+autenticato
  • - Scritto da: 00101010
    > Sono per caso l'unico a pensare che ogni scheda
    > in un diverso processo sia un inutile dispendio
    > di risorse, quando per ovviare ad eventuali
    > blocchi basterebbe inserire nella VM che gestisce
    > il codice ECMAScript un controllo anti-freeze
    > (così come fa
    > opera)?

    Tutti i browser hanno un controllo anti-freeze di Javascript. Alcuni dopo un tot di istruzioni (IE), altri dopo un tot di tempo (FF e Webkit vari)

    > E se qualcuno salta su a dire che lo sviluppo
    > multiprocesso migliora le performance è la volta
    > buona che lo prendo a badilate sui denti; un
    > processo per scheda causa un decadimento delle
    > prestazioni esponenziale all'aumerntare delle
    > schede oltre un certo valore
    > n.

    E` parzialmente vero (non è esponenziale), ma finche` n < numero_di_core è l'esatto opposto, le prestazioni aumentano linearmente.

    Bye.
    Shu
    1232
  • - Scritto da: Shu
    > E` parzialmente vero (non è esponenziale), ma
    > finche` n < numero_di_core è l'esatto opposto, le
    > prestazioni aumentano
    > linearmente.
    >
    > Bye.

    Hai ragione; tuttavia vorrei farti notare che è più realistico pensare che una persona abbia 10 schede aperte su un dual core che ne abbia aperte 2 su un deca core...
    non+autenticato