Hallo Rolf,

ein Beispiel: ich nutze die JS lib html2canvas um von einem bestimmten node (in einem geladenen iframe mit same origin source) ein Bild zu generieren. Und je nach Komplexität des Nodes ist das sehr rechenintensiv und blockiert dann den Main-Thread sehr lange (Anmerkung: Ich kann den Node bzw. das HTML Dokument nicht beieinflussen - auch wenn es same origin ist - und es ist auch notwendig, dass Bild zu erstellen). Ich kann das Ganze nun in einen anderen Tab auslagern und das Ergebnis dann via Channelcast zurücksenden. Das funktioniert auch. Nur möchte ich es eben vermeiden, dass neue Tabs im Browser geöffnet und automatisch geschlossen werden (auch via channelcast).

Ich verstehe einfach nicht, warum es keinen "Dom Worker" gibt, der für so etwas genutzt werden könnte. Nach meinem Wissen hat doch Firefox und Chromium nun die Grundlagen geschaffen, dass jeder Tab in einem eigenen Thread läuft. Deshalb sollte es doch möglich sein, so eine Art "Shadow tab" bereitzustellen.

Gruss Michael

Hallo Jürgen und Michael,

es gibt diverse Ansätze - aber welcher passt, dafür muss man den Anwendungsfall kennen. Darum habe ich danach gefragt.

requestAnimationFrame hängt an der Framerate und am Layout-Zyklus. Ob das bei einer zeitintensiven Hintergrundberechnung ideal ist, weiß ich nicht. Ich würde deshalb lieber setTimeout(func, 0) nehmen. Ich habe auch mal queueMicrotask probiert, aber wenn eine Funktion sich selbst als Microtask queued, blockiert das UI.

Grundsätzlich ist ein Hintergrundprozess, der mit dem DOM rummacht, gefährlich. Das DOM kann sich durch Benutzerinteraktionen verändern, und der Benutzer kann durch DOM-Änderungen, die der Hintergrundprozess macht, behindert werden. Das DOM ist aus gutem Grund single-threaded. Der Use-Case muss daher sehr speziell sein und der Rest der Seite darauf abgestimmt sein, dass da ein Worker tobt. In Jürgens Beispiel ist das so - der Worker ermittelt, was zu zeichnen ist und seine Effekte sind auf den Canvas begrenzt.

Wenn ein Worker - weshalb auch immer - nicht praktikabel ist, muss man sich den UI-Thread mit dem Benutzer teilen. Und man muss gut überlegen, ob man nicht den Stand des DOM, mit dem man anfängt, als Schnappschuss speichern sollte.

In Windows 2 gab es die yield-Funktion, mit der ein Prozess die CPU freiwillig abgeben konnte. Das gibt's heute nicht mehr, aber es gibt ein yield-Statement in JavaScript. Das versteckt sich in Generatorfunktionen.

Die dienen zwar eigentlich zur Erzeugung einer Wertefolge, aber konzeptionell bieten sie mit dem yield-Befehl zwei wichtige Möglichkeiten:

• Suspendieren des Generatorablaufs, ohne den Kontext zu verlieren. Insbesondere kann ein yield tief in irgendwelchen Strukturblöcken stecken. Zwar nicht in Funktionen, die der Generator aufruft, aber die kann man zur Not als Untergenerator schreiben.
• Hereingeben von Steuerdaten aus der Iteratorschleife

Hier als Beispiel eine sehr simple Verarbeitungsschleife, die als Generator verpackt ist. Sie durchläuft ein Array und tut pro Element irgendwas. Die Variablen foo und bar speichern übergreifende Daten für die Varbeitung.

Da der Rückgabewert eines Generators ein Iterator ist, kann man keine eigenen Werte zurückgeben. Ein result-Parameter, in dem Rückgabewerte platziert werden können, umgeht das.

Entscheidender Punkt ist die yield-Anweisung, an der der Generator unterbricht und dorthin zurückkehrt, wo next() aufgerufen wurde. Im Generator selbst muss lediglich "oft genug" yield aufgerufen werden. Die Zeitsteuerung wird vom Iterierer übernommen.

function* runComplexThing(data, result) {
   let foo = 0, bar = 0;
   result.value = undefined;

   for (let i=0; i<data.length; i++) {
     // data[i] verarbeiten;
 
     if (yield i) break;;
   }
}

Ein Generator muss mit einer Iteration durchlaufen werden. Dazu kann man for...of verwenden, aber in einer for...of Schleife lässt sich der JavaScript-Ablauf nicht unterbrechen. Die Alternative zu for...of ist das manuelle Durchlaufen mit der next()-Methode:

const result = {};
const dataWringer = runComplexThing(data, result);
runWringStep(dataWringer, (aborted) => handleResult(result, aborted));

function runWringStep(generator, onComplete) {
  // Maximale Step-Zeit: 100ms (beispielsweise)
  const stepStart = Date.now();
  while (Date.now() - stepStart < 100) { 

    // Optional: Abbruchbedingung, z.B. Timeout oder Cancel-Button
    const abort = /* true um abzubrechen, false zum weitermachen */

    // Wert von abort ist Ergebnis von yield
    const genValue = generator.next(abort);  
    // genValue enthält den Iteratorstatus
    if (genValue.done) {
       onComplete(abort);
       return;
    }
  }
  setTimeout(runWringStep, 0, generator, onComplete);
}

Dieses Snippet durchläuft den Generator, bis die Generatorfunktion endet (done ist dann false). Wenn nach einer Anzahl von next()-Aufrufen zu viel Zeit vergangen ist, wird setTimeout verwendet, um zunächst das UI zu bedienen und den Generator im nächsten Durchlauf der JavaScript-Eventloop weiter zu verarbeiten. Die Zeit von 100ms muss man an den Anwendungsfall anpassen, 100 ist aber schon die Obergrenze für halbwegs flüssiges UI.

Wenn man einen Abbruchmöglichkeit vorsehen will, kann man das auf unterschiedliche Art tun. Im Beispiel übergebe ich ein bool an next(), was zum Rückgabewert von yield wird. Statt dessen kann man auch die return()- oder throw()-Methode des Generators verwenden.

Ich denke, daraus könnte man einen Wiki-Artikel machen: Vordergrund-Worker mit Generatoren. Dort würde ich das Ergebnis noch in ein Promise verpacken und einen AbortController unterstützen…

Rolf