So my understanding of the reading is there are two ways to code: synchronous and asynchronous. In synchronous everything is executed line by line and the previous line needs to be completed before moving on. In asynchronous programming, asynchronous operations can be called then run concurrently with the rest of the code until they're completed and "recaptured" by the code, so the previous line does not need to be completed before moving on. The order of and memory using by asynchronous operations are managed by the event loop. These two ways of coding can be mixed, and asynchronous programming can be achieved in three ways: callback functions, promises, and async/await. Am I missing anything big?

I think this is a really good summary. Of course, limiting yourself to synchronous code is, well, limiting. Things happen concurrently, and we need to be able to program in a world of concurrency.

Event Loop.

When I/O occurs, with a callback, the event loop puts the rest of the computation in an area for things waiting for events (event handlers). When the I/O completes, the event handler is called to continue the computation.

I’m curious about the differences between the event loop model in JavaScript and the models for other languages. The stack frame set-up seems relatively similar to that for C that we learned about in CS240, but the runtime is very different - how does this effect memory use? Does one model use more memory than the other?

Great question! Yes, you're on the right track. In CS 240, you learned about stacks. One way to deal with concurrency is multiple stacks. This works great and has a lot of power.

However, stacks require more memory than an event-loop architecture, which is a different way of handling concurrency (but limited mostly to I/O).

Something I didn’t understand from the readings was single-threading (and threading in general); what does that mean?

A thread is a computation with a stack, so you can have concurrent or even simultaneous computations.

Could we go over why in the asynchronous call back function, if we added a print statement after the readFile, “the print statement would happen before the I/O completes and therefore would be printed before the line that we read from the file”?

Let's look at that. It's just before the section on event loop

What happens if outside the asynchronous function in the more work section from the website there is something that depends on the thing being finished? (not sure if this makes sense). What then?

It does make sense. If something depends on the thing being finished, we need to make sure it's in the (1) callback or (2) in the .then() or (3) after the await.

The syntax of the different executions were a little hard to follow and would love them to be covered a bit more in class.

Sure. We'll go over all of them. They are all the same idea in different syntaxes.

Can we go over Fetch API and show a few examples of promises?

Yes, let's do that with the question assignment.


    p1 = fetch("https://cs.wellesley.edu/cs304node/questions/questions/");
    p2 = p1.then( (resp) => resp.json() );
    p2.then( (resp) => glob = resp );

fetch, what is a response object exactly?

It's an object that the browser creates to represent the response from the server. The response will typically contain some data, maybe with headers and such.

I am still a bit confused about the advantages of and when should we use promises and callbacks over async/await

async/await is the newest, shiniest version. It makes programming much easier, but it does sacrifice some concurrency. (For example, you might want to make several simultaneous requests.) We won't worry about that scenario until much later, if ever, so for CS 304, we can focus on await.

Going over how .then() works, and async/await in general

The demo earlier should help. The then attaches a function (an event handler) to be called when/if the promise is fulfilled. async/await does a similar thing, but with the rest of a function:


    async function foo() {
       let x = line1();
       let y = await someIO; 
       let z = f(y);

The async/await means that the function execution gets put on hold for the duration of the I/O and the f(y) has to wait until the I/O completes. So, the rest of the function is like the code in a .then().

Why do we need catch() when we have the second argument in then?

Great point. It's just an alternative.

I think that once I see a demo of these topics I'll be more comfortable with them

For sure!

I'd honestly just like to practice the asynchronous methods of doing I/O in class if there's time. It'll be easier to conceptualize the three methods once we've practiced them.

Yes.

More coding practice with using these concepts!

We will. Our programming interface with MongoDB will use await.