而且每個synchronous function call都會令到其他async function變成synchronous
硬係有啲人 Promise.resolve(getFibonacci(100)) 就當自己 async 咗, 到發現 event loop被block死就投訴個framework寫得唔好。用 async construct 包住sync function嘅真正問題係 tie up user thread, 而唔係令其他async function 變返 sync。 包 sync function 包到block死 event loop 或 main thread 係低級錯誤, 係唔熟framework, 同 tie up user thread 根本係2個完全唔同嘅問題。 tie up user thread 呢啲係死症, 個個framework都有async db driver你唔用, 你一定要 legacy API 就自己睇路, 咩framework都幫唔到你。
C#就時不時有人直接用Task.Result, 搞到有bottleneck甚至deadlock
呢啲又係低級錯誤, code review 叫佢記得 async all the way, UI thread 要ConfigAwait(false) 之類, 再犯就炒得。
就係因為咁,nodejs嘅生態先顯得神奇,所有API day 1已經係用async function設計出嚟
13年前或者係, 但今時今日一街都係web framework, 全部by default async io, 再吹奏呢樣嘢, 同你30歲仲吹奏自己中學係名校有乜分別 ?
BTW, ASP.NET Core 已經唔再建議libuv
咁不如你再睇多啲,佢哋用咩嚟代替 libuv, 點解,同埋結果。
asp.net core 嘅 event loop 放棄咗 libuv loop, 用 c# 重寫。
點解個event loop要重寫 ?因為 libuv 仲係用 linux thread pool去處理disk IO (包括db) / network IO, 而無用到 linux 嘅 aio。
Linux AIO 透過 batching send/recv in networking IO (同 disk IO 嘅batching 原理一樣) 去減少 IO 嘅overhead, performance 高於 thread pool。
結果就係 libuv 嘅 IO 慢過 kestrel, 亦係nodejs喺performance上輸比
asp.net core嘅其中一個原因, 某啲 benchmark 有3X 嘅分別。
但快又如何,單靠呢啲web framework都食唔到真正嘅大茶飯。
如果將 complex system 比喻為一間酒樓, asp.netcore / nodejs 呢啲web framework就好似門口嘅知客, 負責派飛帶位,偶然收下銀,僅此而已。以前啲經理on99叫知客落場斟茶, 推點心車,甚至入廚房煮飯, 門口梗係排長龍, 客人等等吓咪走人囉。
microservice / step function (aws) or durable function (azure) 都係解決呢類問題嘅其中一個辦法, 總之個結論係 nodejs is good but it's not that good,
asp.net core is great but it won't be tomorrow.