Quiz

Still not sure about I/O
I/O is both critical (can't have a useful computer program without it) and difficult, because I/O is extremely different from processing (arithmetic, logic, computation, etc). So the design of computer systems has to provide and integrate both. CS 240 talks about this a bit.
What 240 probably says is that, when a process P wants to do I/O
- It does a system call, allowing the OS to take control
- The OS puts the process in a data structure of tasks waiting on I/O
- It starts the I/O
- It transfers control of the processor (CPU) to some other process, Q, on the queue of runnable processes
- When the I/O completes, the OS interrupts whatever task (Q or someone else) is running
- puts the data in memory for the first process, P
- Puts P on the queue of runnable processes
- Continues the interrupted task
In an Event-Loop architecture, processes are never interrupted. They run until they want to do I/O, whereupon the Event Loop creates a Promise that represents the continuation of that computation, once the I/O is complete.
So, it's an entirely different way of combining I/O with computation.
I'm still slightly confused about blocking vs non-blocking in how they deal with error. In asynchronous (non-blocking) version, if the author does not decide that the error should throw, what other options are there that doesn't lead to crashing?

Sure. I didn't talk much about errors, but you don't have to crash. You could catch the error and tell the user that the file wasn't there, or the data was corrupted or whatever. You could try wait and try again. You could try a different file.
That's pretty much the same whether you are using blocking or non-blocking I/O.
promises
A promise represents the rest of the computation, after the I/O resolves (succeeds or fails). Each of those is a function that continues the computation from there.
```
    const p = fetch("some url");  // returns a Promise
    p.then(functionAfterSuccess);
    p.catch(functionOnFailure);
```
Async/Await
This reading is a bit more difficult to understand. Can we go over async and await in class please?
Yes, this is a very difficult reading. I had a lot of trouble wrapping my mind around promises and async/await when I first learned them. Be patient with yourselves. You'll get it.
Working with Promises is great, but awkward and requires chopping up our computation into little chunks.
Async/Await is a language feature that allows us to program as if things were blocking/synchronous.
When the I/O begins, the function is suspended and it (the async function) is the then() continuation when the promise resolves. It's as if we were able to wrap .then() around the rest of our function body.
```
    const data = await fetch("some url");
    console.log("we fetched ", data.length, " items of data");
    // ...
```
The above works pretty much the same as:
```
    fetch("some url").then( function (data) { 
        console.log("we fetched ", data.length, " items of data");
        // ...
        });
```
When is it better to use .then() chaining vs. async/await? Are there performance differences or just syntactic differences?
Great question! Because async/await gives us the illusion of living in a synchronous world, it doesn't allow us to (easily) do things concurrently. Suppose I want to request 2 things:
```
    const data1 = await fetch("some url");
    const data2 = await fetch("some other url");
    console.log("we fetched ", data1, " and ", data2, " sequentially");
    // ...
```
But that does them sequentially. Or, I can do it in parallel:
```
    const p1 = fetch("some url");
    const p2 = fetch("some other url");
    Promise.all([p1, p2]).then(
        () => console.log("we fetched ", data1, " and ", data2, " concurrently");
    );
    // ...
```
The Promise.all() resolves when all the promises have resolved. See MDN Promise.All()
We will not be using Promise.all. We'll stick to async/await. But I wanted to answer the question.
Can we talk more about how when to use await and/or promises?

In this class, we'll focus on async/await, but you should understand that they create an illusion of sequentiality in a concurrent world built on promises.
Could you explain more about why we want to use asynchronous functions instead of synchronous ones? Are there examples of writing functions asynchronously significantly improve the performance/is necessary? Thanks

Doing things concurrently is great and can improve performance, but at the cost of complexity.
In practice, we often don't need concurrency. We get some data, modify it, store it back. That's sequential. So async/await works very well.
What does it mean that async functions always return promises?

Those are the rules of the game. Async functions start some asynchronous operation (usually I/O) and so they return a Promise, and the caller has to either wait or work with the promise.
Once things are asynchronous, all the callers are, too.
Could we discuss more on the logic of this function and how we can get what the data variable stores?
```
async function getData() {
    let resp = await fetch("https://cs.wellesley.edu/cs304node-questions/questions/");
    let data = await resp.json();
    console.log('got', data.length, 'questions');
    console.log(data);
}
```
For sure! The first line initiates a request. Think of it as sending a minion off to get something for you.
You, the boss, wait for your minion to return with a response.
Later, the minion returns and says "the data is on its way!"
You wait for the data to finish arriving
Later, the data arrives and you can process it in the usual way that you are used to.
Maybe we could talk more about the Fetch API?

Glad to. The Fetch API takes a URL, initiates a network request to the server, and returns a Promise that will resolve when the network request returns.