Rust/Wasm çalışma zamanı güvenilirliği, hem panik hem de iptal kurtarma işlemlerinin yapılmasını gerektirir

Wasm ilk bakışta kolaylıkla bir taşıma katmanı olarak görülebilir: kod programlanabilir, sayfa çalıştırılabilir, performans iyidir ve her şey hemen hemen aynı gibi görünür. Genellikle demo geçildikten sonra gerçekten zorlaşmaya başlar. Düzenleyiciler, oluşturucular ve belge ayrıştırıcılar gibi modüller tek sayfalık denemelerden uzun vadeli yerleşik çalışma sürelerine geçtiğinde hata modelleri hemen değişecektir.

Şu anda panik ve iptal artık dil katmanında istisna dalları değil. Karar verdikleri şey şu: Bu örneğin sonraki işleri almaya devam edip edemeyeceği, bellekteki durumun bozuk olup olmadığı, ana bilgisayar katmanının örneği hemen atması gerekip gerekmediği ve örnek havuzunun doldurulması gerekip gerekmediği. Mobil ekip, yerel kapsayıcılarda uzun süredir çalışan bir çekirdeği Web’e taşıdığında, en kolay şekilde hafife alınan şey bu değişim katmanıdır.

Demo geçildikten sonra arıza modeli yeni başladı.

Tek bir aramadaki çökmeleri anlamak zor değil. Bir düğmeye tıklamak bir Wasm çağrısını tetikler. Başarısız olursa, işlem için bir hata rapor edilecektir. Sayfayı yenileyip tekrar deneyin. Maliyet hâlâ kontrol edilebilir.

Sorun, çalışma zamanı örnekleri yeniden kullanmaya başladıktan sonra ortaya çıkar. Aynı Wasm örneği sürekli olarak birden fazla belge açtığında, birden fazla giriş olayı turu aldığında ve birden fazla JS köprü çağrısından geçtiğinde panik ve iptalin etki kapsamı artık mevcut eylemde durmaz. Tamamlanmamış bir başarısızlık sonraki istekleri olumsuz etkileyebilir.

Bu tür riskler çoğu zaman ilk gün ortaya çıkmaz. İlk aşamada, genellikle yalnızca dağınık hata raporları görürsünüz: ara sıra işleme hataları, belirli bir dışa aktarmanın takılıp kalması ve belirli bir belgenin kapatılıp yeniden açıldıktan sonra yanlış durumda olması. Daha fazla kontrol ederseniz, ipuçları yavaş yavaş aynı olguya doğru birleşecektir: Arıza bir çağrı zincirinde meydana gelmiş olsa da, hasar paylaşılan örnekte kalmıştır.

Bu noktada tartışmanın odağı artık “Rust kodunun panik yapıp yapmayacağı” değil, "Bu çalışma zamanının panik sonrasında bir sonraki çağrıyı sunmaya devam etmeye uygun olup olmadığı"dır.

Panik yakalanabilir, iptal sadece örnekleri değiştirebilir.

Rust/Wasm’da ayrılması gereken en önemli şey, iki başarısızlık semantiği olan panik ve iptaldir.

Panik aynı zamanda belirlenmiş sınırlara geri dönme fırsatına da sahiptir. Bağlama katmanı ve ana bilgisayar katmanı kurtarma yöntemi üzerinde önceden anlaştıkları sürece mevcut çağrı başarısız olabilir ve örnekteki diğer durumlar da korunabilir. iptal etmek kesinlikle gidilecek yol değildir. Bu, mevcut yürütmenin kurtarılamaz bir duruma ulaştığı anlamına gelir. İstekleri almak için aynı örneği kullanmaya devam ederseniz, aslında hafızanın ve kaynakların yarı yolda zarar görmeyeceğine dair bahse girersiniz.

Bu ikisi çalışma sırasında birbirine karıştırıldığında sonraki işlemlerde kesinlikle sorunlar ortaya çıkacaktır:

• Normal bir istisna olarak yutmayı iptal edin ve örnek havuzu, güvenilirliğini kaybetmiş nesneleri yeniden kullanmaya devam edecektir.
• Tüm paniklere, örneğin yok edilmesi gerekiyormuş gibi davranın; bu durumda verim gereksiz yere azalacaktır
• JS ana bilgisayarı yalnızca “çağrının başarısız olduğunu” bilir ancak yeniden denemeyi, örneği kaybetmeyi veya mevcut oturumu kesmeyi bilmiyor

Bu aynı zamanda Wasm çalışma zamanı güvenilirliği ile ilgili en gerçekçi şeydir: sonraki izolasyon ve planlamanın uygulanabilmesi için öncelikle kurtarma semantiğinin tanımlanması gerekir.

Bağlama katmanı kurtarma semantiğini sağlamıyorsa, ana bilgisayar katmanı kötü durumu alır ve işi kabul etmeye devam eder.

Bu tür bir sorun için en tehlikeli yer iş kodu değil, “zaten halledilmiş” gibi görünen bağlayıcı katmandır. Ana bilgisayar katmanı genellikle yalnızca atılan bir hata nesnesini görür ve bunu normal bir çağrı hatası olarak kaydeder. Günlük oradadır ve sayfa hemen çökmez, ancak sistem kötü durumu örneğin içinde bırakmış olabilir.

Gerçekten düzeltilmesi gereken şey sadece deneme/yakalama değil, başarısızlık sonrasındaki müdahale eylemleridir. Aşağıdakine benzer bir mantık, güvenilirlik tasarımına yeni girmeye başladı:

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

Bu kodun odak noktası söz dizimi değil, basit bir karardır: mevcut hatanın bu örneği güvenilmeyen bir nesne olarak işaretleyip işaretlemediği. Cevap evet ise, kurtarma eylemi hata atmakla sınırlı kalmamalı; örneğin ortadan kaldırılmasına, kaynakların yeniden yapılandırılmasına ve akışın kesilmesine kadar devam etmelidir.

Bu katman açıkça tanımlanmadığı sürece sistem hataları yönetiyor gibi görünecektir, ancak aslında yaptığı şey potansiyel olarak bozulmuş bir çalışma zamanını üretim yoluna geri koymaktır.

Paylaşılan örnekler, kurtarma sorununu bir havuz oluşturma stratejisi sorununa dönüştürecek

Wasm gerçek ürünlere uygulandıktan sonra nadiren “sayfa kapatılana kadar tek bir örnek” olur. Örnek havuzları, çalışan havuzları veya bir dizi çalışma zamanı kaynağını paylaşan ön plan belgeleri ve arka plan görevleri daha yaygın olanlardır. Bu aşamada panik ve iptalin kurtarma maliyetleri, havuzlama stratejisini doğrudan yeniden yazacaktır.

Örneğin başlatılması pahalıysa, sistem doğal olarak onu mümkün olduğunca yeniden kullanma eğiliminde olacaktır. Ancak yeniden kullanım sağlandıktan sonra arıza izolasyonunun da aynı anda yükseltilmesi gerekir:

• Hangi durumlar yalnızca tek bir çağrıda askıya alınabilir ve başarısızlıktan sonra çağrıyla birlikte atılır
• Aramalarda hangi önbelleklerin tutulmasına izin verilir ve iptalle karşılaşıldığında hangi önbelleklerin tamamen geçersiz kılınması gerekir
• Örnek değiştirildikten sonra sıraya alınan görevler nasıl taşınacak? Tekrar denemek iki kez yan etkilere neden olur mu?

Bunlar dil katmanının otomatik olarak göndereceği yanıtlar değildir. Bunlar çalışma zamanı tasarımlarıdır.

Bu nedenle Rust/Wasm güvenilirliği tartışması sadece “paniğe yakalanabilir mi?” sorusuyla biterse, sorunu hafife almak kolaydır. Bakım maliyeti açığını gerçekten genişleten şey, örnek havuzunun bir arıza sonrasında net bir güven sınırını koruyup koruyamayacağıdır.

Uygulanabilir sınır yaşam döngüsüyle güçlü bir şekilde ilişkilidir

Bu restorasyon tasarımları seti her Wasm projesi için gerekli değildir.

Modül yalnızca tek seferlik bir çevrimdışı araçsa veya sayfa yok edildiğinde örneğin tamamı geri dönüştürülürse, panik ile iptal arasındaki fark yine de mevcut olacaktır ancak kurtarma faydası çok daha küçük olacaktır. Doğrudan sayfayı yenilemek ve görevi doğrudan yeniden çalıştırmak genellikle yeterlidir.

Sistem aşağıdaki özelliklere sahip olduğunda, kurtarma semantiği hızla bir "optimizasyon öğesi"nden "altyapı öğesi"ne dönüşecektir:

• Örnek uzun süre kalır ve tek sayfalık yaşam döngüsüyle birlikte yok edilmez
• Aynı örnek sürekli olarak birden fazla çağrı turu gerçekleştiriyor
• Barındırma katmanının, başlatma süresi ve aktarım hızı karşılığında havuz oluşturmayı kullanması gerekir
• Arıza sonrasında oturum durumunu, önbellek durumunu ve sıradaki görevleri koruyun

Mobil ekipler yerel yetenekleri Web’e taşıdığında, karşılaşılması en muhtemel sınır bu sınırdır. Başlangıçta Uygulama sürecinde varsayılan olarak kurulan izolasyon ilişkisinin, JS/Wasm ana makine sınırına ulaşıldıktan sonra sıklıkla yeniden doldurulması gerekiyordu.

Wasm, yerel kodun tarayıcıya girmesini kolaylaştırır, ancak çalışma zamanı kurtarma anlamını beraberinde getirmez. Sistem örnekleri paylaşmaya, durumu yeniden kullanmaya ve uzun vadeli çağrıları kabul etmeye başladığında, panik ve iptal iki farklı çalışma zamanı olayı olarak ele alınmalıdır. İlki mevcut çağrının nasıl sonlandırılacağıyla ilgilenirken, ikincisi bu örneğin havuzda yaşamaya devam edip edemeyeceğiyle ilgileniyor. Eğer bu karar ilk önce verilmezse, kod nakli ne kadar başarılı olursa, daha sonraki başarısızlıklarla baş etmek de o kadar zor olacaktır.