LUA協程的介紹

lua 有一套非常高效的協程機制, 這一套實現非常輕量級, 雖然簡單意味著高效, 然而它并不是真正意義上的對稱式協程. lua中使用 coroutine.create 來創建一個協程, 使用 coroutine.resume 來執行協程。使用 coroutine.yield 來讓出當前正在執行的協程. 通過這兩個函數,你可以在兩個協程之間相互傳遞參數, 直到協程執行完成.

local function f(a1)-- 讓出協程,傳遞 a1+1 值給resume函數local ret = coroutine.yield(a1+1)-- 讓出協程,傳遞 ret+1 值給resume函數return coroutine.yield(ret+1) end-- 這里創建一個協程 local co = coroutine.create(f) -- 執行f 協程, 當前協程會被掛起 print(coroutine.resume(co, 1)) print(coroutine.resume(co, 12))

通過上面的例子可以看出, lua的協程只能yield 給 resume方. 也就是說 你在協程內任意地方yield 那么resume 會立刻返回.

異步IO

假定我們希望使用一套異步io庫來結合LUA的協程來做開發， 會遇到哪些問題呢？首先異步IO會有一個事件循環, 比如 libuv 的 uv_run. 它們所有的操作都是通過回調來完成的. 如果采用完全相同的編程方式,這肯定沒太多意義, 對簡化編程幫助也不大。編程同步化更加符合人的思維習慣, 開發起來也會更加簡單.

想的方案是, 當我們調用一個io操作的時候, 掛起當前協程, 在收到網絡事件的時候再恢復它的執行. 編程方法將會變成下面這樣:

-- 連接通信函數 local function connhandler(conn)while true do--- 循環從客戶端讀取數據local data, reason = conn.read(10000)if 110 == data then-- 超時elseif 'string' == type(data) then--讀取到了數據conn.write(data)else-- 出錯了, 或者連接斷開breakendendprint('conn has gone') end-- 服務器循環等待客戶端連接 local function serverloop(server)while true do-- 等待一個連接local retv, message = server.wait(10000)if false == conn thenbreakelseif 110 == conn then-- wait timeoutelse-- 得到了一個連接 retv is conncoroutine.resume(connhandler, retv)endend endlocal server = tcp.server('0.0.0.0', 80) coroutine.resume(serverloop)--這里是一個事件循環 uv.run()

這里完美將回調函數給隱藏了, 使用一個 while 循環來等待客戶端的連接. 在得到一個連接的時候, 我們創建了一個協程來處理這個連接的所有業務.
在 和連接通信的時候 conn.read conn.write 我們會掛起當前協程， 將控制權轉移給 serverloop 以讓 server 能繼續去接受新的連接. 這樣做的并發能力還是不錯的. 通常情況下, 執行不會有問題的。例如如下的流程:

connhandler 進行IO操作 掛起 -> serverloop 開始執行.

serverloop 執行等待連接操作, 掛起, 這個時候進入了 lua的 mainthread.

第一個連接有數據到達.

mainthread 恢復 connhandler 協程.

lua 的一個協程創建后, 你可以在任何地方 resume 它, 然而它的 yield 卻只能 將執行控制權交給 resume 方.

然而 這樣做也還是存在一些問題. 繼續分析一下:
原因在于 connhandler 掛起并不總是為了等待 conn的io操作返回. 假定我們在 connhandler 中執行了另外一個異步io, 比如 發起一個http請求, 這個時候 這個conn 剛好有數據回來. 整套執行流程就亂了. ^_

解決辦法:

我們只有在 顯式uv_read_start, 在lua中 conn.read 的時候執行 uv_read_start, on_read 回調中取到數據后立即 uv_read_stop. 即可.

接下來我們可以放心地在 connhandler 去調用其它的異步IO.操作. 我們可以確保一個io操作導致的等待， 只會被該io操作的回調結果 resume 即可.

如何做?

下面給出示意代碼:

// tcp.read 函數uv_read_start(conn, uv_onread);lua_pushthread(L);conn->read_ref = luaL_ref(L, LUA_REGISTERYINDEX, -1);return lua_yield(L, 0);// 讀取到數據的回調結果.uv_onread(...)uv_read_stop(conn)// resume read_ref 協程 并傳遞讀取結果.

至此, 我們已經實現了將異步io同步化的改造, 在框架中 我們僅需要實現 tcpserver tcpclient udp pipe 進程池 等的封裝, 包括ssl支持的具體的上層應用可以全部使用lua來完成.

Channel 實現

本來打算利用純lua來實現channel的， 畢竟 協程之間的相互 yield 和resume 不就是現成的channel么? 然而，看起來很香, 事實上可能沒那么簡單. 原因是 脫離了 libuv 的事件循環后,純語言層 進行 yield resume 優先級太高了. 假定你在業務場景中死循環使用channel 通信, 只在兩個協程中間相互 yield resume的話， 這個時候 main thread 將永遠沒機會執行。其它io事件都沒機會執行.

雖然 lua 的協程之間的 yield resume 效率很高, 但還是不得不做一些取舍, 借助 uv_async_send 來實現 channel.

push 的時候, 我們將數據加入到一個隊列中. 并執行 uv_async_send.

channel->pop 執行的時候, 先檢查隊列,如果有數據直接返回這條數據. 如果沒有. 掛起當前協程. 等到 uv_async_cb 的 resume 喚醒.

可以使用 uv_timer 來實現超時. 這里不多作說明.

后注

這套實現已經在項目中得到應用, 目前工作良好.

總結

以上是生活随笔為你收集整理的在LUA中使用异步IO的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。