https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2024F_Lecture_15 2026-05-12T21:38:51Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2024F_Lecture_15&diff=24827&oldid=prev 2024-11-07T19:49:03Z

<p>Created page with &quot;==Video== Video from the lecture for November 7, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec15-20241107.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec15-20241107.cc.vtt auto-generated captions] ==Notes== &lt;pre&gt; Lecture 15 ---------- - I am behind on Teams messages &amp; email - should be caught up by Saturday afternoon - Assignment 3 coming out in the next...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture for November 7, 2024 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec15-20241107.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec15-20241107.cc.vtt auto-generated captions]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 15<br /> ----------<br /> - I am behind on Teams messages &amp; email<br /> - should be caught up by Saturday afternoon<br /> - Assignment 3 coming out in the next day<br /> - based on Tutorial 7 code<br /> - note all current tutorials are due next week<br /> - please get caught up!<br /> <br /> Why can&#039;t you call await inside of a regular function?<br /> - regular functions must complete executing, they cannot pause<br /> - async functions can be paused, with them resuming execution at some arbitrary later time<br /> - callers of regular functions expect them to complete!<br /> - so if you want to do something async from a synchronous function,<br /> you have to use a callback function that will be run once the async<br /> function completes<br /> <br /> the then method is used to resolve returned promises by registering a callback function. The callback function will be called when the promise is fulfilled.<br /> <br /> <br /> So if you are calling a function or method that is asynchronous (and thus returns a promise always), you can either<br /> * use await if it is being called inside of an async function<br /> * use then if it is being called inside of a synchronous function<br /> <br /> So why is req.json() asynchronous?<br /> - we have the request, isn&#039;t the body just part of that object?<br /> - NO, it is potentially still being sent by the client (browser)<br /> - it could be a big file being uploaded!<br /> - so the request object can be used to get the body, but it isn&#039;t there yet<br /> - we use methods like .formData() and .json() to get the body data and process it<br /> - thus, when you&#039;re debugging and you look at the request, you won&#039;t see<br /> the request body there - you have to ask for it explicitly instead<br /> <br /> Can you use .then on a promise in an async function?<br /> - yes, but it makes your code unnecessarily complex most of the time<br /> - instead, just use await and then your code reads sequentially<br /> rather than having a callback function stuck in the middle of it<br /> <br /> JavaScript code, particularly on the server, often got stuck in &quot;callback hell&quot; before the introduction of async/await<br /> - callbacks nested inside callbacks nested inside callbacks<br /> - became very hard to follow the flow of control of the code<br /> <br /> The .then method makes callbacks cleaner when used with promises, but still not as good as async/await.<br /> <br /> <br /> Remember that web servers are highly concurrent<br /> - you have many clients connecting &quot;at once&quot; (multiple requests can be pending)<br /> - calls to the database can take arbitrary time<br /> - calls to the filesystem can take arbitrary time<br /> <br /> So when this happens you have two choices<br /> - synchronous: your code pauses until the requested operation finishes, doesn&#039;t do anything else<br /> - asynchronous: your code pauses the particular code waiting for something but other parts of the app can keep running<br /> <br /> Deno implements what is known as &quot;cooperative multitasking&quot;<br /> - different execution contexts pause their work when they are waiting for data but don&#039;t block the execution of other code in the app<br /> <br /> Compare this to code in standard Java, Python, or C<br /> - when you open or read a file, or access the network,<br /> those calls are blocking, meaning<br /> - the code executes sequentially<br /> - when making a call that may not complete immediately, the<br /> rest of the app pauses until that action finishes, e.g.<br /> a read() from a file pauses execution until the read finishes,<br /> no other code runs<br /> <br /> What if you want your code to do something useful while operations are pending, in standard Java, Python, or C?<br /> - you use threads or processes<br /> - i.e., you logically have multiple copies of the program running at the same time<br /> - each one runs independently<br /> - with threads, they share memory and so can coordinate that way<br /> - with processes, they each have exclusive copies of memory, and so<br /> coordination has to happen in some other way (sockets, files)<br /> <br /> with pthread library in C, threads can be implemented in multiple ways<br /> - kernel &amp; userspace threads, or a mix of the two<br /> - beyond the scope of this class, but pretty darn complex<br /> <br /> But what we&#039;ve found is that<br /> 1) processes are heavyweight and make coordination hard<br /> 2) threads are a pain because interrupting execution means that<br /> threads interleave in arbitrary ways, meaning we need locks<br /> on data structures to prevent corruption<br /> 3) cooperative multitasking is more efficient and easier to program,<br /> when done with the right abstractions<br /> <br /> Deno implements cooperative multitasking with callback functions, promises (and the syntactic sugar of async/await)<br /> <br /> This is a complex topic, covered more in operating systems.<br /> <br /> But just know<br /> - in the first web servers (and many other UNIX servers), every incoming request caused a new process to be created, with that new child process handling the incoming request while the parent waited for new incoming connections<br /> - web servers on windows couldn&#039;t do this because process creation was too expensive, so they made a new thread for each incoming request. UNIX servers adopted the same architecture to keep up in performance<br /> - later it was realized threads were too expensive to create so often,<br /> so they made &quot;thread pools&quot; of already existing threads that would<br /> take care of a request and then go back to the pool to wait for new ones<br /> - node.js demonstrated that cooperative multitasking could be used to make<br /> simpler and extremely fast web servers. Deno followed the lead<br /> - was possible because node developed a new async-first approach<br /> to I/O<br /> <br /> Oddly enough, JavaScript was the perfect language for making a cooperative multitasking web server because it originated in the web browser, and so it had no standard facilities for dealing with files or regular network I/O.<br /> <br /> - today you can do async I/O (facilitating cooperative multitasking) in Java, Python, and C/C++; however, it is not the default and you end up mixing sync and async code, and that can cause problems without considerable care<br /> <br /> <br /> State and http<br /> - In general, APIs can be stateful or stateless<br /> - stateful APIs generally allow for smaller requests and can improve performance through tricks like caching<br /> - stateless APIs however can allow for greater parallelism<br /> because any necessary context is included with the request<br /> <br /> <br /> Classic UNIX file API is stateful<br /> - you have to open a file, get a file descriptor<br /> - that file descriptor has to be used for subsequent operations<br /> - and that file descriptor should be released when no longer needed<br /> (i.e., closed), although that happens automatically when a process terminates<br /> <br /> Why is it stateful?<br /> - because there&#039;s a good bit of work required when finding the data<br /> associated with a filename<br /> - using a file descriptor allows this work to amoritized across multiple<br /> operations (multiple read&#039;s and write&#039;s)<br /> - but then we need to tell the OS that we no longer need to access the file<br /> so it can release the associated resources, that&#039;s why files should be closed<br /> <br /> http, however, is a stateless protocol<br /> - every request is independent, GET /list can be understood<br /> without reference to any other http request<br /> - this has been very useful for scaling the web<br /> - because you can do things like replicate web servers<br /> and any server can handle any incoming request<br /> <br /> HOWEVER, in general we need state in a web app (as opposed to just serving static web documents). So what do we do?<br /> - this is where cookies come in<br /> - not the only solution, but a very common one<br /> <br /> We need some way to tie groups of requests together, indicate they are associated with the same browser/same user<br /> <br /> Basic idea<br /> - server sends some data to the client on first connection<br /> - on later connections, the client sends this data back to the server<br /> so the server knows who it is talking to<br /> <br /> It is like a &quot;ticket&quot; that is given out and then later can be used to show that you&#039;ve paid for a service.<br /> <br /> Whevever you &quot;log in&quot; to a website, there is state, and that state is maintained using things like cookies.<br /> &lt;/pre&gt;</div>

Soma