Generetor函式與執行緒之間的思考
摘要：
在解析這個問題之前，首先，我們來了解一下es6標準裡新增解決非同步的兩種規範
Promise與Generetor
Promise
其實Promise的本質 還是基於js程式的回撥處理————這一點看它的原始碼封裝，或者將它通過ATS(抽象語法樹)解析成es5，我們可以得出這樣的結論...
在解析這個問題之前，首先，我們來了解一下es6標準裡新增解決非同步的兩種規範
Promise與Generetor
Promise
其實Promise的本質 還是基於js程式的回撥處理————這一點看它的原始碼封裝，或者將它通過ATS(抽象語法樹)解析成es5，我們可以得出這樣的結論。
當需要一定等待時間才能執行並返回結果的事件，我們稱之為非同步。
那麼Promise是怎樣處理的呢？
Promise是基於社群早已有的解決方案，在es6中將它標準化了。
我們可以從它的字面意思中得到它的處理形式 —— 承諾。
也就是說，當js執行緒 接受一個promise非同步時，此時它會先返回一個承諾(此時這個非同步扔到了非同步佇列中的promise佇列)
—— 意思是你先幹其他事，這個事處理完了我會給你個結果(當從非同步佇列裡拿出來扔到執行棧執行後，出來結果時)。
沒辦法啊單執行緒嘛。
這是典型的非同步IO式解決方案。
如圖：
fuck dog，以前有圖的，找不到了，現畫了一張。主要對比下面的generetor
Genegetor
而generetor的解決方案，並非是基於js程式的回撥處理。
這一點，es6規範裡提到過：
xxxxxxxx…(詳情請參考es6標準文件)
簡單說一下核心思想：
generator是通過輪詢解決的非同步。
後面說總結。
那麼什麼是輪詢呢？
上圖：
ok，從圖中你可以get 到,輪詢即週期性的訪問執行緒，是否已執行完該操作。
如果從js直譯器的角度來講：
就是把非同步直接扔到事件佇列，排序壓入執行棧(等待時間也看作是執行時間)執行。
也就是所謂的把非同步 同步序列化。
非阻塞式執行緒與generetor函式之間不得不說的祕密
未完待續。