Voor de betrouwbaarheid van de Rust/Wasm-runtime is zowel het omgaan met paniek als het afbreken van herstel vereist

Wasm kan in eerste instantie gemakkelijk worden beschouwd als een portlaag: de code kan worden geprogrammeerd, de pagina kan worden uitgevoerd, de prestaties zijn in orde en de zaken lijken ongeveer hetzelfde te zijn. Het begint echt moeilijk te worden, meestal nadat de demo is afgelopen. Zodra modules zoals editors, renderers en documentparsers overgaan van experimenten met één pagina naar langdurige runtimes, zullen de foutmodellen onmiddellijk veranderen.

Op dit moment zijn paniek en afbreken niet langer uitzonderingstakken in de taallaag. Wat ze beslissen is: of deze instantie vervolgwerk kan blijven ontvangen, of de toestand in het geheugen vervuild is, of de hostlaag de instantie onmiddellijk moet weggooien en of de instantiepool gevuld moet worden. Wanneer het mobiele team een ​​kernel die al lange tijd in native containers draait naar het web verplaatst, wordt deze laag van verandering het gemakkelijkst onderschat.

Nadat de demo is geslaagd, is het foutmodel zojuist gestart.

Crashes tijdens één oproep zijn niet moeilijk te begrijpen. Een klik op de knop activeert een Wasm-oproep. Als dit mislukt, wordt er een fout gerapporteerd voor de bewerking. Vernieuw de pagina en probeer het opnieuw. De kosten zijn nog steeds beheersbaar.

Het probleem treedt op nadat de runtime exemplaren begint te hergebruiken. Wanneer dezelfde Wasm-instantie continu meerdere documenten opent, meerdere rondes met invoergebeurtenissen ontvangt en meerdere JS-bridge-oproepen passeert, stopt de reikwijdte van de invloed van paniek en afbreken niet langer bij de huidige actie. Een onvolledige mislukking kan volgende verzoeken vertragen.

Dergelijke risico’s zijn vaak niet op de eerste dag zichtbaar. In de eerste fase zie je meestal slechts verspreide foutmeldingen: incidentele weergavefouten, een bepaalde export loopt vast en een bepaald document verkeert in een onjuiste staat nadat het is gesloten en opnieuw geopend. Als je verder kijkt, zullen de aanwijzingen geleidelijk convergeren naar hetzelfde fenomeen: hoewel de fout plaatsvond in een oproepketen, bleef de schade in de gedeelde instantie.

Op dit punt ligt de focus van de discussie niet langer op “of de Rust-code in paniek zal raken”, maar op “of deze runtime gekwalificeerd is om de volgende oproep na de paniek te blijven bedienen”.

Paniek kan worden opgevangen, afbreken kan alleen instanties veranderen.

Het belangrijkste om te scheiden in Rust/Wasm is de twee mislukkingssemantieken: paniek en afbreken.

Paniek heeft ook de mogelijkheid om terug te ontspannen langs gevestigde grenzen. Zolang de bindingslaag en de hostlaag het van tevoren eens zijn over de herstelmethode, kan de huidige oproep mislukken en kunnen ook andere statussen in de instantie behouden blijven. afbreken is helemaal niet de juiste weg. Dit betekent dat de huidige uitvoering een onherstelbare status heeft bereikt. Als u dezelfde instantie blijft gebruiken om verzoeken te ontvangen, wedt u er feitelijk op dat het geheugen en de bronnen niet halverwege beschadigd raken.

Zodra de twee tijdens runtime met elkaar worden gemengd, zullen er zeker problemen optreden bij de daaropvolgende verwerking:

• Slik abortus als een normale uitzondering, en de instantiepool zal objecten blijven hergebruiken die hun geloofwaardigheid hebben verloren.
• Behandel alle panieksituaties alsof de instantie moet worden vernietigd, waardoor de doorvoer onnodig wordt verminderd
• De JS-host weet alleen “de oproep is mislukt”, maar weet niet of hij het opnieuw moet proberen, de instantie moet verliezen of de huidige sessie moet afbreken

Dit is ook het meest realistische aan de betrouwbaarheid van de Wasm-runtime: de herstelsemantiek moet eerst worden gedefinieerd voordat daaropvolgende isolatie en planning kunnen worden geïmplementeerd.

Als de bindingslaag geen herstelsemantiek biedt, zal de hostlaag de slechte status aannemen en het werk blijven accepteren.

De gevaarlijkste plaats voor dit soort problemen ligt niet in de bedrijfscode, maar in de bindende laag, die “al opgelost” lijkt te zijn. De hostlaag ziet vaak alleen een gegenereerd foutobject en registreert dit als een normale oproepfout. Het logboek is aanwezig en de pagina crasht niet onmiddellijk, maar het systeem heeft mogelijk de slechte status in de instantie achtergelaten.

Wat echt moet worden opgelost, is niet alleen try/catch, maar ook de afhandeling na een mislukking. Logica vergelijkbaar met de volgende is net begonnen in het betrouwbaarheidsontwerp:

async function runWithRecovery(instance, input) {
  try {
    return await instance.exports.handle(input)
  } catch (error) {
    if (isAbort(error)) {
      pool.replace(instance.id)
    }
    throw error
  }
}

De focus van deze code ligt niet op de syntaxis, maar op een eenvoudig oordeel: of de huidige fout deze instantie als een niet-vertrouwd object heeft gemarkeerd. Als het antwoord ja is, moet de herstelactie niet ophouden bij het genereren van fouten, maar moet deze doorgaan tot het elimineren van instanties, het reconstrueren van hulpbronnen en het beperken van de verzoekstroom.

Zolang deze laag niet duidelijk is gedefinieerd, lijkt het erop dat het systeem fouten afhandelt, maar wat het feitelijk doet is een mogelijk beschadigde runtime terug in het productiepad brengen.

Gedeelde instanties zullen het herstelprobleem vergroten tot een poolstrategieprobleem

Nadat Wasm in echte producten is geplaatst, is er zelden slechts “één exemplaar totdat de pagina wordt gesloten”. Vaker zijn exemplaarpools, werkerpools of voorgronddocumenten en achtergrondtaken die een set runtimebronnen delen. In dit stadium zullen de herstelkosten van paniek en abortus de poolingstrategie direct herschrijven.

Als instance-initialisatie duur is, zal het systeem uiteraard de neiging hebben om deze zoveel mogelijk te hergebruiken. Maar zodra hergebruik tot stand is gebracht, moet de foutisolatie tegelijkertijd worden geüpgraded:

• Welke statussen kunnen slechts in één oproep worden opgehangen en worden na een mislukte oproep samen met de oproep weggegooid
• Welke caches mogen worden behouden tijdens oproepen, en welke caches volledig ongeldig moeten worden gemaakt zodra er sprake is van afbreken
• Hoe worden de taken in de wachtrij gemigreerd nadat het exemplaar is vervangen? Zal het opnieuw proberen twee keer bijwerkingen veroorzaken?

Dit zijn geen antwoorden die de taallaag automatisch verstuurt. Het zijn runtime-ontwerpen.

Hierdoor is het gemakkelijk om het probleem te onderschatten als de discussie over de betrouwbaarheid van Rust/Wasm alleen eindigt bij “kan er paniek worden opgevangen?”. Wat het verschil in onderhoudskosten echt vergroot, is of de instancepool na een storing een duidelijke vertrouwensgrens kan handhaven.

De toepasselijke grens is sterk gerelateerd aan de levenscyclus

Deze set restauratieontwerpen is niet voor elk Wasm-project vereist.

Als de module slechts een eenmalige offline tool is, of als de hele instantie wordt gerecycled wanneer de pagina wordt vernietigd, zal het verschil tussen paniek en afbreken nog steeds bestaan, maar zal het herstelvoordeel veel kleiner zijn. Vaak is het voldoende om de pagina direct te vernieuwen en de taak direct opnieuw uit te voeren.

Zodra het systeem de volgende kenmerken heeft, zal de herstelsemantiek snel veranderen van een “optimalisatie-item” naar een “infrastructuuritem”:

• De instantie blijft lange tijd aanwezig en wordt niet samen met de levenscyclus van één pagina vernietigd
• Dezelfde instantie voert voortdurend meerdere oproeprondes uit
• De hostinglaag moet pooling gebruiken in ruil voor opstarttijd en doorvoer
• Bescherm de sessiestatus, cachestatus en taken in de wachtrij na een fout

Wanneer mobiele teams native mogelijkheden naar het web verplaatsen, is de kans het grootst dat deze grens wordt aangetroffen. De isolatierelatie die oorspronkelijk standaard in het App-proces tot stand werd gebracht, moest na het bereiken van de JS/Wasm-hostgrens vaak opnieuw worden ingevuld.

Wasm maakt het gemakkelijker voor native code om de browser binnen te komen, maar brengt geen runtime-herstelsemantiek met zich mee. Zodra het systeem instances begint te delen, de status opnieuw gebruikt en langdurige oproepen accepteert, moeten paniek en afbreken worden behandeld als twee verschillende runtime-gebeurtenissen. De eerste maakt zich zorgen over hoe het huidige gesprek moet worden beëindigd, en de laatste maakt zich zorgen of deze instantie in de pool kan blijven leven. Als dit oordeel niet eerst wordt gemaakt, geldt: hoe succesvoller de codetransplantatie is, des te moeilijker het zal zijn om met daaropvolgende mislukkingen om te gaan.