3 回答

TA貢獻1865條經驗 獲得超7個贊
在我開始為我想要并發的 Web 服務編寫適配器之前,我對此有您的看法。我有一個必須啟動的 go 例程來解析從 web 調用返回到通道的結果。如果不將其用作 go 例程,則絕對不會出現此 API 可以工作的情況。
然后我開始查看像 net/http 這樣的包。該包中有強制并發。在接口級別記錄它應該能夠同時使用,但是默認實現會自動使用 go 例程。
因為 Go 的標準庫通常在它自己的包中觸發 go 例程,我認為如果你的包或 API 有保證,你可以自己處理它們。

TA貢獻1801條經驗 獲得超16個贊
我目前的觀點是我們應該記錄并給調用者一個選擇。
我傾向于同意你的看法。
由于 Go 使并發運行代碼變得如此容易,因此您應該盡量避免 API 中的并發(這會迫使客戶端并發使用它)。相反,創建一個同步 API,然后客戶端可以選擇同步或并發運行它。
特別是幻燈片 26,顯示的代碼更像您的第一個示例。
我會將該net/http
包視為一個例外,因為在這種情況下,并發幾乎是強制性的。如果包沒有在內部使用并發,客戶端代碼幾乎肯定必須使用。例如,http.Client
(據我所知)不會啟動任何 goroutine。只有服務器這樣做。
在大多數情況下,無論哪種方式,它都將是調用者的一行代碼:
go Run()
?或者?StartGoroutine()
同步 API 并不難同時使用,并為調用者提供更多選擇。

TA貢獻1799條經驗 獲得超9個贊
沒有“正確”的答案,因為情況不同。
顯然,在某些情況下,API 可能包含實用程序、簡單算法、數據集合等,如果打包為 goroutines 會看起來很奇怪。
相反,在某些情況下,自然會期望“幕后”并發,例如豐富的 IO 庫(http 服務器就是一個明顯的例子)。
對于更極端的情況,請考慮您要生成即插即用并發服務庫。這樣的 API 由模塊組成,每個模塊都通過通道具有詳細描述的接口。顯然,在這種情況下,它不可避免地會涉及作為 API 一部分的 goroutine。
一個線索很可能是函數參數中是否存在通道。但我希望清楚地記錄兩種方式的預期結果。
- 3 回答
- 0 關注
- 221 瀏覽
添加回答
舉報