Wawancara WASI 0.3: Bagaimana Async, Stream, dan Future Melintasi Komponen?

Petunjuk dan Konteks

Sebuah plugin host menjalankan komponen yang ditulis dalam beberapa bahasa. Komponen yang ada bergantung pada resource wasi:io WASI 0.2, sedangkan komponen baru menginginkan async func, stream, dan future WASI 0.3. Rancang antarmuka untuk log streaming, panggilan jarak jauh (remote call), dan pembatalan. Jelaskan bagaimana host menjadwalkan pekerjaan, membatasi sumber daya, dan menjaga agar komponen lama tetap berfungsi.

Ini menguji semantik asinkron pada batas ABI, bukan apakah setiap fungsi ditandai sebagai async. WASI.dev menjelaskan 0.3 sebagai penambahan native async dan pembaruan antarmuka (refactoring); FAQ Component Model menyebutkan bahwa wasi:io dihapus dan kesiapan dibawa melintasi batas melalui primitif Component Model. Jawaban yang kuat memisahkan kontrak antarmuka, penjadwalan runtime, dan efek samping bisnis.

Hal yang Dievaluasi Pewawancara

Pertama, klasifikasikan operasi sebagai hasil tunggal, stream berkelanjutan, atau panggilan jangka panjang yang dapat dibatalkan. Kemudian pilih future, stream, atau return biasa. Jelaskan mengapa resource pollable 0.2 menciptakan "masalah sandwich" pada batas komponen dan bagaimana 0.3 memungkinkan runtime mengelola propagasi penungguan dan bangun (wake-up).

Jawaban ini juga memerlukan backpressure, batas sumber daya, kelas kesalahan, dan strategi migrasi. "Async lebih cepat" tidak memberikan banyak penjelasan; pewawancara menginginkan pemahaman tentang ritme konsumen, penyelesaian future, efek samping pasca-pembatalan, dan jalur adaptor untuk komponen lama.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

Nilai tunggal atau stream berkelanjutan

Tanyakan apakah panggilan jarak jauh mengembalikan satu respons atau memancarkan log, potongan file, atau event. Gunakan future untuk satu hasil dan stream untuk urutan inkremental dengan sinyal akhir eksplisit dan kebijakan kapasitas. Jika konsumen dapat menjeda, tentukan batas buffer dan perilaku produsen.

Apakah pembatalan harus mencegah efek samping?

Tentukan lokasi pembatalan dalam siklus hidup: dalam antrean, sedang dieksekusi, atau setelah penulisan eksternal. Batas komponen dapat membawa permintaan pembatalan, tetapi tidak dapat membatalkan (rollback) efek samping eksternal yang telah dilakukan. Itu memerlukan kunci idempoten (idempotency key), pengecekan status, atau kompensasi.

Bisakah kedua versi berjalan selama migrasi?

Konfirmasikan apakah host dapat memuat 0.2 dan 0.3 secara bersamaan, apakah komponen lama harus tetap tidak berubah, dan apakah runtime mendukung adaptor. Jawaban tersebut menentukan runtime berdampingan (side-by-side), adaptor 0.2-ke-0.3, atau cutover terkoordinasi.

Kerangka Jawaban 30 Detik

"Saya memilih primitif berdasarkan semantiknya: hasil jarak jauh sekali jalan (one-shot) menggunakan future, log berkelanjutan menggunakan stream terbatas (bounded), dan komputasi murni sinkron tetap sinkron. WASI 0.3 menempatkan kesiapan dan wake-up ke dalam ABI native Component Model daripada membuat setiap komponen memiliki pollable. Host tetap menetapkan batas konkurensi, buffer, tenggat waktu (deadline), dan pembatalan; pembatalan menghentikan pekerjaan lebih lanjut tetapi menggunakan status idempoten untuk efek eksternal. Saya mempertahankan world 0.2 selama migrasi dan beralih melalui adaptor serta matriks kompatibilitas."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Tempatkan semantik async di world WIT

Definisikan antarmuka sekecil mungkin; jangan membuat setiap fungsi menjadi asinkron. Pseudocode bergaya WIT ini memisahkan stream dari hasil tunggal:

package acme:plugin@0.3.0;

interface logs {
  record chunk { bytes: list<u8>, end: bool }
  export next: func() -> future<chunk>
}

world worker {
  import logs;
  export run: async func(input: string) -> result<string, failure>;
}

Sebuah future menunjukkan satu nilai yang akan datang, bukan tugas latar belakang tanpa batas. Sebuah stream digunakan untuk urutan yang dikirimkan seiring waktu. Antarmuka juga harus mendefinisikan kesalahan, akhir stream (end-of-stream), dan status pasca-pembatalan; jika tidak, binding yang dihasilkan dalam berbagai bahasa dapat mengalami ketidaksesuaian.

Langkah 2: Jelaskan batas 0.2 ke 0.3

WASI 0.2 mengekspresikan kesiapan I/O dengan pollable, input-stream, dan output-stream. Sebagai resource komponen, kesiapannya harus melintasi lapisan async pemanggil dan terpanggil yang terpisah, menghasilkan masalah sandwich. WASI 0.3 menggunakan primitif async func, future, dan stream sehingga runtime dapat mempropagasi kesiapan melintasi komponen.

Ini bukan penulisan ulang paksa dari biner lama. FAQ resmi menjelaskan bahwa runtime 0.3 dapat memetakan impor 0.2 ke primitif 0.3 pada batas host. Pertahankan world lama, biarkan adaptor melakukan translasi, dan tingkatkan versi komponen satu per satu.

Langkah 3: Berikan batas backpressure dan memori pada stream

Produsen tidak dapat menulis selamanya. Tetapkan batas elemen, byte, dan waktu tunggu per stream. Ketika konsumen tertinggal, jeda pembacaan atau kembalikan hasil kelebihan beban (overload) yang eksplisit. Isolasi buffer perantara berdasarkan penyewa (tenant) dan komponen sehingga satu konsumen lambat tidak menghabiskan memori runtime. Untuk file dan log, teruskan potongan (chunks) atau handle terkontrol alih-alih menyalin objek lengkap melintasi batas.

Langkah 4: Rancang pembatalan future dan kesalahan

Sebelum future selesai, simpan ID operasi, deadline, dan sinyal pembatalan. Pembatalan harus menghentikan pekerjaan yang belum dimulai dan mengirimkan penghentian kooperatif ke kode yang sedang berjalan. Jika layanan eksternal mungkin telah melakukan penulisan, tandai status sebagai UNKNOWN; lakukan kueri dengan kunci idempoten atau lakukan kompensasi alih-alih mencoba ulang secara membabi buta. Bedakan antara batas waktu habis (timeout), pembatalan, penolakan bisnis, kegagalan dependensi, dan ketidakcocokan protokol sehingga masing-masing mendapatkan kebijakan percobaan ulang yang sesuai.

Langkah 5: Pertahankan penjadwalan di dalam runtime

Komponen tidak boleh masing-masing memulai event loop tersembunyi untuk kelas I/O yang sama. Runtime host memegang kendali atas wake-up, konkurensi, dan keadilan (fairness); komponen mendeklarasikan antarmuka dan mengembalikan hasil. Pertahankan hot path sinkron yang pendek tetap sinkron untuk menghindari pembuatan tugas yang tidak perlu. Roadmap Bytecode Alliance mencatat bahwa infrastruktur async pada panggilan sinkron dapat menambah overhead, jadi lakukan benchmark pada adaptor sinkron, batas async, dan pekerjaan bisnis secara terpisah.

Langkah 6: Bangun migrasi bertahap dan matriks verifikasi

Catat paket WIT, versi WASI, runtime, adaptor, dan digest komponen dalam manifes rilis. Uji komponen 0.2 pada host 0.3, komponen 0.3 pada host yang lebih lama, pembatalan di tengah stream, efek samping tidak diketahui setelah timeout, konsumen lambat, dan koneksi ulang. Jalankan shadow pada jalur baru dan bandingkan tingkat penyelesaian, latensi end-to-end, buffering puncak, latensi pembatalan, dan percobaan ulang sebelum peluncuran bertahap berbasis versi.

Contoh Jawaban Berkualitas Tinggi

Saya tidak akan menandai setiap antarmuka sebagai async. Saya akan mengklasifikasikan setiap operasi: hasil jarak jauh sekali jalan mendapatkan future, log berkelanjutan mendapatkan stream, dan komputasi lokal murni tetap sinkron. Perubahan kunci pada WASI 0.3 adalah menempatkan async func, future, dan stream ke dalam ABI native Component Model, menggantikan resource pollable wasi:io 0.2 sehingga kesiapan dan wake-up dapat melintasi batas komponen.

Pada saat runtime, saya akan membatasi elemen stream, byte, dan waktu tunggu. Konsumen yang lambat akan menjeda produksi atau menerima sinyal kelebihan beban; konsumen tersebut tidak dapat menggunakan memori bersama tanpa batas. Future membawa ID operasi dan deadline. Pembatalan menghentikan pekerjaan yang belum dimulai, sedangkan penulisan eksternal menjadi UNKNOWN dan diselesaikan melalui pencarian kunci idempoten atau kompensasi, bukan mencoba ulang secara membabi buta.

Untuk migrasi, saya mempertahankan world 0.2 dan memetakannya pada batas host menggunakan adaptor, kemudian melakukan shadowing dan peluncuran bertahap berdasarkan versi komponen. Matriks mencakup komponen lama dan baru, pembatalan, backpressure, kesalahan, dan koneksi ulang. Jika runtime atau toolchain belum mendukung 0.3, saya menunda pengalihan world daripada berpura-pura bahwa ABI tersebut kompatibel.

Kesalahan Umum

• Kesalahan → Memperlakukan future sebagai tugas latar belakang umum → Alasan gagal → Future adalah satu hasil yang dapat diselesaikan; siklus hidup dan pembatalan tetap memerlukan kontrak → Solusi → Lacak ID operasi, deadline, dan status pembatalan.
• Kesalahan → Menggunakan antrean tak terbatas untuk lonjakan stream → Alasan gagal → Konsumen lambat mengubah tekanan memori menjadi pemadaman runtime → Solusi → Batasi byte dan elemen, lalu teruskan backpressure atau tolak secara jelas.
• Kesalahan → Mengklaim bahwa 0.3 secara otomatis membatalkan (rollback) penulisan eksternal → Alasan gagal → Pembatalan ABI bukanlah transaksi terdistribusi → Solusi → Gunakan idempotensi, pencarian status, dan kompensasi.
• Kesalahan → Menghapus world 0.2 dengan segera → Alasan gagal → Komponen dan toolchain lama mungkin masih bergantung pada resource pollable → Solusi → Migrasi melalui adaptor dan matriks kompatibilitas.
• Kesalahan → Memberikan setiap komponen event loop-nya sendiri → Alasan gagal → Penjadwalan, pembatalan, dan keadilan menjadi tidak konsisten → Solusi → Biarkan runtime mengelola wake-up dan alokasi konkurensi.

Pertanyaan Lanjutan dan Tanggapan

Lanjutan 1: Produsen melampaui konsumen. Buang data atau tahan (block)?

Klasifikasikan datanya terlebih dahulu. Log dapat membuang catatan dengan tingkat keparahan lebih rendah sambil menghitung jumlah yang dibuang; transaksi keuangan tidak boleh hilang begitu saja, jadi simpan ke antrean eksternal terbatas dan kembalikan backpressure. Dalam kedua kasus, tampilkan ID penyewa, komponen, dan stream dalam metrik daripada hanya melihat throughput agregat.

Lanjutan 2: Bagaimana Anda mengetahui apakah future yang kehabisan waktu (timed-out) telah selesai?

Timeout berarti pemanggil berhenti menunggu, bukan berarti operasinya telah di-rollback. Simpan ID operasi dan lakukan kueri pada dependensi. Tanpa API status, tandai hasilnya sebagai UNKNOWN dan serahkan ke proses kompensasi atau operator. Coba lagi hanya jika kontrak menjamin idempotensi dan pemeriksaan status mengonfirmasi bahwa operasi tersebut belum selesai.

Lanjutan 3: Komponen 0.2 menggunakan pollable. Bagaimana host 0.3 mengekspos perilaku yang setara?

Adaptor memetakan event resource 0.2 ke future atau stream 0.3 sambil mempertahankan semantik penutupan, kesalahan, dan pembatalan. Pertama, bandingkan urutan kesiapan dan EOF dalam pengujian komponen tunggal, lalu uji komposisinya. Jika adaptor hanya mengemulasikan sebagian dari perilaku tersebut, deployment gate harus menolak world yang memerlukan antarmuka yang hilang tersebut.

Lanjutan 4: Bagaimana Anda membuktikan bahwa penulisan ulang ke async membuahkan hasil?

Bagi pengukuran menjadi waktu adaptor, wake-up runtime, buffering puncak, CPU, memori, latensi end-to-end, dan tingkat penyelesaian bisnis, lalu bandingkan dengan baseline sinkron. Untuk panggilan yang sangat singkat dengan sedikit waktu tunggu konkuren, manajemen tugas dan adaptasi ABI dapat menghilangkan manfaatnya; pertahankan antarmuka sinkron atau gunakan pemrosesan batch untuk panggilan tersebut.