協程系列之Event Loops

Event Loops

事件循環

事件是由程序的一部分在特定條件下發出的消息，循環是在某種條件下完成並執行某個程序直到它完成的構造，所以，事件循環是一個循環，它容許用戶訂閱事件傳輸並註冊處理程序/回調。 它使程序可以以異步方式運行。事件循環將它收到的全部事件委託給各自的回調，大多數回調模式的實現都有一個主要缺點，他們以引入大量嵌套的方式規定編程風格。所以，爲了表示程序的某些部分彼此依賴，咱們使用排序，然而，在依賴於異步結果的狀況下，出現瞭如下模式：

• 嵌套回調，以便內部回調能夠訪問外部回調的結果（閉包）
• 使用充當將來結果代理的對象（所謂的 Future 或 Promise ）
• 協程，它是在事件循環中運行的可掛起函數

Nesting Callback（嵌套回調）

嵌套回調的經驗法則是，若是須要等待回調的結果，則必須將代碼嵌入到相應的回調中。你很快就會陷入臭名昭着的回調地獄般的局面。回調地獄是回調嵌套的深度，這使得程序的推理和改進成爲一種噩夢。

Futures/Promises

Futures/Promises 是封裝異步調用的結果和錯誤處理的對象。它們最終會提供 APIs 來查詢results/exceptions 的當前狀態，以及註冊回調來處理 results/exceptions 的方法。因爲它們封裝了異步調用的將來上下文並須要嵌套，所以生成的程序彷佛以更自上而下的方式編寫。(.then那種形式)

Coroutines

你能夠簡單把協程理解爲能夠中斷的函數。暫停意味着咱們能夠在函數任何位置暫停協程。這意味着它必定有某種原子單位組成。這就是咱們所說的 tick，也就是咱們所測量的 tick。tick 是事件循環的時間單位， 它包含在事件循環的一個迭代步驟中發生的全部操做

協程實際上能夠作得更多：它們能夠暫停本身並等待另外一個協同程序的結果。 waiiting 的全部邏輯由事件循環協調，由於它知道相應的協程狀態

Asyncio中事件循環的生命週期

asyncio中的事件循環有四種狀態： 1.Idle 2.Running 3.Stopped 4.Closed 您能夠經過四種事件循環方法與事件循環的生命週期進行交互，這些方法能夠分爲啓動，中止和關閉方法。 它們構成了事件循環生命週期接口，全部 asyncio /第三方事件循環都須要提供兼容性。

1.run_forever 2.run_until_complete

調用 run_forever 方法時沒有參數，而 run_until_complete 方法須要傳入一個協程函數做爲參數。要中止，咱們可使用 stop 方法；要關閉，咱們使用 close 方法。

The Idle State(空閒狀態)

空閒狀態是建立循環後所處的狀態。在此狀態下不消耗任何協程或者回調函數。在這個狀態下 loop.is_running 返回 False。

The Running State(運行狀態)

運行狀態是在調用 loop.run_forever 或 loop.run_until_complete 以後循環所處的狀態。在這個狀態下 loop.is_running 返回 True。 這些方法之間的區別在於，在 loop.run_until_complete 的狀況下，loop.run_until_complete 會將協程被包裝在 asyncio.Future 中。回調在 asyncio.Future 對象上註冊爲處理程序，該對象在徹底消耗協程後運行loop.stop 方法。

The Stopped State(中止狀態)

中止狀態是調用stop命令後循環所處的狀態。調用stop方法後，調用is_running方法不會返回False，首先消耗全部掛起的回調。只有在它們被消耗以後，循環纔會進入空閒狀態。

The Closed State(關閉狀態)

循環經過調用close方法進入關閉狀態。只有當循環不處於運行狀態時，才能調用它。

事件循環的基本類

在Python 3中默認提供兩種事件循環。 抽象事件循環類由asyncio.events和asyncio.base_events模塊提供。 AbstractEventLoop和BaseEventLoop表示事件循環實現的兩個潛在類。

AbstractEventLoop

AbstractEventLoop類定義了原生asyncio中事件循環的接口。 接口方法能夠大體分爲如下幾個部分

• 生命週期方法(運行、中止、查詢狀態和關閉循環)
• 調度方法
• 回調
• 協程
• 建立Future對象
• 線程相關的方法
• IO操做相關的方法
• 低層級API(socket, pipe, and reader/writer APIs)
• 高層級APIs(server, pipe, and subprocess-related methods)
• 信號方法
• 調試標誌管理方法

該應用編程接口是穩定的，在手動事件循環實現的狀況下能夠被子類化

BaseEventLoop

儘管基於更高級別的組件，但不該使用BaseEventLoop類來建立手動循環實現，由於它的API不穩定。 但它能夠做爲一個如何實現接口的指南。 它的BaseEventLoop._run_once方法在循環的每一個tick上調用，所以包含一次迭代所需的全部操做。這將調用全部當前準備好的回調，I/O輪詢，調度生成的回調，而後調度call_later回調，若是您計劃本身實現事件循環，則須要提供與其相似的方法，函數的名稱和主體只是實現細節。

事件循環是特定於操做系統的嗎？

是的，事件循環是特定於操做系統的 這可能會影響API可用性和事件循環的速度。 例如，add_signal_handler和remove_signal_handler是僅限UNIX的循環API。 除了缺乏相應的本機綁定以外，操做系統特性背後的緣由之一是大多數環路都是基於selectors模塊實現的。selectors是基於select模塊的提升的高級I/O多路複用接口。 selectors模塊創建在Select, poll, devpoll, epoll, or kqueue之上，具體取決於底層操做系統。selectors模塊中的模塊負責設置默認選擇器，而默認選擇器又被異步模塊使用。

if 'KqueueSelector' in globals():
   DefaultSelector = KqueueSelector
elif 'EpollSelector' in globals():
   DefaultSelector = EpollSelector
elif 'DevpollSelector' in globals():
   DefaultSelector = DevpollSelector
elif 'PollSelector' in globals():
   DefaultSelector = PollSelector
else:
  DefaultSelector = SelectSelector

注意在Windows中還有一個基於I/o完成端口或短IoCP的ProactorEventLoop類實現 IOCP的官方文件將它們描述爲「在多處理器系統上處理多個異步輸入輸出請求的有效線程模型」。例如，若是須要使用asyncio子進程API，能夠在Windows上使用ProactorEventLoop。 後續，會不斷完善。 更多精彩內容請關注公衆號:python學習開發