Knut Grimsrud schrieb:
. . ., selbst bei uBlock Origin. Hmm
Firefox: uBlock Origin WebExtension released [ghacks.net, By
Martin Brinkmann on October 30, 2016 in
Firefox - Last Update: June 25, 2017]
Zum Thema Add-Ons und WebExtensions
Die Zukunft geht klar in die Richtung von CPUs mit mehreren Kernen/Threads, da das sich der Takt pro Kern nicht mehr wie früher steigern lässt. Die neue Render-Engine Servo ist von Beginn an auf Parallelität ausgelegt. Die
Roadmap zeigt auch, dass Teile wo möglich in Firefox integriert werden
Our long-term plan is to:
- Incrementally replace components in Firefox with ones written in Rust and shared with Servo.
Der Quantum Compositor ist in der Nightly-Version 52 integriert worden (
Next-Generation-Engine: Quantum Compositor landet in Firefox Nightly [soeren-hentzschel.at, 05.12.2016]), das CSS-System erst vor kurzem.
Project
Servo zeigt eindrucksvoll wie performant die parallele Ausführung von Prozessen/Threads ist. Die Zukunft gehört der
Parallelisierung (
Nebenläufigkeit) von Prozessen/Threads, was mit dem bestehenden Kern und XUL nicht möglich ist. Was bei System on a Chip (SoC) bereits länger der Fall ist und in CPU Themen bis vor kurzem - vor Ryzen - immer gefordert wurde, ist dass die Anzahl von physischen Kernen/Threads sich erhöhen muss. Mit Ryzen, Ryzen Threadripper, Skylake-X alias Core i9 und Cannon Lake sind jetzt mindestens 6 Kerne/12 Threads im Mainstrem angekommen. In den Themen wurde auch mehrfach gefordert, dass die Software dies unterstützen muss. Ziel ist es mit
Quantum sukzessive Entwicklungen aus Mozillas Projekt
Servo in Gecko zu integrieren. Dies geht aber nur, wenn der Kern entsprechend angepasst wird.
Es ist sehr komplex eine Anwendung für die
Parallelisierung (
Multitasking,
Nebenläufigkeit) von Prozessen/Threads zu entwickeln, da bei der
Parallelisierung Konflikte auftreten können. Aktuell kommt es bereits zu Problemen in Zusammenhang mit Add-Ons, die verschwinden, wenn das entsprechende Add-On deaktiviert wird. Das Risiko weiterhin in die Tiefen, wie dies mit XUL möglich ist, eingreifen zuzulassen und gleichzeitig
Parallelisierung (
Nebenläufigkeit) von Prozessen/Threads sicher zu stellen, ist extrem bzw. nicht möglich, da es schnell zu
Konflikten kommt.
Konflikte wikipedia.org schrieb:
Der
Kontext jedes
Programmteils muss vor unerwarteter
Veränderung durch andere Teile geschützt werden (
Synchronisierung). Soll ein gemeinsamer
Zugriff auf
Daten realisiert werden, wobei zumindest eine Partei schreibend/verändernd zugreifen möchte, dann muss der Zugriff synchronisiert werden, bspw. durch
gegenseitigen Ausschluss (
Mutex) unter Benutzung von
Monitoren oder von
Semaphoren. Alternativ kann auch verlangt werden, dass bestimmte Aktionen von zwei Prozessen
gemeinsam ausgeführt werden, mit so genannten
Rendezvous. Eine weitere sichere Art der Kommunikation sind
Warteschlangen. Diese Techniken lösen das Problem des gleichzeitigen Zugriffs auf
Ressourcen, verhindern jedoch keine Verklemmungen (ganz im Gegenteil).
Bereits jetzt verursachen Add-Ons Performance-Probleme, Abstürze, usw. Dies würde sich durch
Parallelisierung (
Nebenläufigkeit) von Prozessen/Threads potenzieren. Dies ist auch der Grund warum dies in Chromium von Anfang an nicht vorgesehen wurde.