So I challenged someone in a code review to prove that there code that made use of async functions wouldn’t be susceptible to a race condition. To that end I came up with a very trivial code example to demonstrate the issue, worth trying to write down the output and line orderings before you read on.<\/p>\n
let list;\r\n\r\nasync function clearList () {\r\n list = []; \/\/ A\r\n}\r\n\r\nasync function processList (processList) {\r\n await clearList(); \/\/ B\r\n list = list.concat(processList); \/\/ C\r\n}\r\n\r\nprocessList([1,2,3]); \/\/ D\r\nprocessList([4,5,6]) \/\/ E\r\n .then(() => {\r\n console.dir(list); \/\/ F\r\n })<\/pre>\nSo the two questions here are what is the output of this code and what order do the lines of code get executed in. Now the point of the code was that it would show that the output is
\n[1,2,3,4,5,6]<\/code> because of the race condition; but the actual ordering of the execution of the lines of code I had wrong.<\/p>\nMy assumption was that you would not enter the async method directly and instead be queued to be performed on a later clock tick. This gave me an execution flow of D,E,B,B,A,A,C,C,F<\/code> which I was happy with until my coworker Millan Kuchtiak pointed out I was entirely incorrectly.<\/p>\nIt turns out that at least in Chrome and Safari that code doesn’t get transferred queue until you reach the first await call. So actually when you run the code through with a debugger the flow is D,B,A,E,B,A,C,C,F<\/code>. This make sense from a performance point of view, some async methods might never need the change of context, so just in time async.<\/p>\nTo summarise\u00a0an async method is synchronous up until the first await<\/b><\/p>\n\n