การดำเนินการแบบอะซิงโครนัสด้วย WASM

When a WebAssembly module performs a complex calculation or a long task, it can freeze your web page. This is because JavaScript is single-threaded, and most direct WASM calls are synchronous.

Asynchronous WASM patterns allow these tasks to run without completely blocking the main browser thread, keeping your UI responsive.

When JavaScript calls an exported WASM function, that function executes entirely before JavaScript regains control. If the WASM function takes a long time, the browser's main thread will be blocked.

This means no UI updates, no user input processing, making the page appear frozen. True parallel execution for WASM often involves Web Workers, which is covered in another lesson.

To prevent blocking the main thread, we can break a long-running WASM task into smaller, manageable chunks. Instead of one huge, blocking WASM call, we make many small ones.

Between each small WASM call, JavaScript can yield control back to the browser's event loop. This allows the UI to update and remain responsive.

Here's a Rust function that represents one "chunk" of work. It takes a starting value and performs a small number of calculations. In a real application, this could process a part of an image or a segment of data.

To handle asynchronous operations, JavaScript uses Promises. A Promise represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

• Pending: Initial state, neither fulfilled nor rejected.
• Fulfilled: Operation completed successfully.
• Rejected: Operation failed.

We use .then() for success and .catch() for errors.

async/await is syntactic sugar built on Promises, making asynchronous code look and behave more like synchronous code, improving readability. It's built on Promises.

• An async function always returns a Promise.
• The await keyword can only be used inside an async function. It pauses the execution until the Promise settles, allowing other tasks to run.

This is crucial for orchestrating our WASM chunks.

We can create a JavaScript utility function that wraps a synchronous WASM call in a Promise. By using setTimeout(..., 0), we tell the browser to execute the WASM call after the current event loop cycle finishes.

This effectively "yields" control back to the browser, allowing it to update the UI before the next WASM chunk runs.

Here's a complete, runnable example demonstrating how to manage a long-running WASM task asynchronously using chunking and JavaScript's async/await.

Notice how `setTimeout(0)` around the WASM call allows the browser to breathe between chunks.

Just like any asynchronous operation, you should handle potential errors. If a WASM chunk call fails (e.g., due to invalid input or memory issues), the Promise will reject.

You can use try...catch with async/await or .catch() with Promises to gracefully handle these situations in your JavaScript code.

Consider a WebAssembly function heavy_calc() that takes 5 seconds to run. If you call it directly from JavaScript's main thread, what is the primary consequence?

We've learned how to handle long-running WASM tasks asynchronously on the main thread without using Web Workers. Key takeaways:

• WASM functions are synchronous when called from JavaScript.
• Break long tasks into smaller "chunks."
• Use JavaScript Promises and async/await to orchestrate these chunks.
• Yield control to the browser's event loop (e.g., with setTimeout(0)) between chunk calls to keep the UI responsive.

This pattern is crucial for maintaining a smooth user experience in complex web applications.