Jarred-Sumner往JavaScriptCore提交了一個合并請求,151次提交只為一件事:讓“new Thread(fn)”這種寫法原地起飛。fn是直接跑在另一個核心上、與主線程共享同一堆內存的普通函數。沒有序列化克隆,沒有消息傳遞,也沒有SharedArrayBuffer那類半吊子逃生艙——共享對象就直接共享對象本身。
當前的狀態有點誠實得可愛:并行JavaScript已經跑通全部四級JIT,且不加全局鎖,線程測試套件也能通過。但還沒完,線程消毒清理、模糊測試、一個指標超預算的基準和漫長浸泡,都橫在“測試能過”和“真能用”之間。鎖回退模式與禁用線程的配置沒動過,PR底部的啟動日志把翻車現場和修復代價寫得明明白白。作者直言,這PR就是放出來讓人讀設計、懟代碼的,它可能永遠不會合入主干。
API是個閉包。線程就是一次跨核函數調用:const t = new Thread((a, b) => expensive(a, b), x, y)。然后t.join()阻塞拿到結果或重拋異常,await t.asyncJoin()用Promise不阻塞。沒有單獨文件、沒有blob URL、沒有打包器配入口、沒有onmessage協議。函數看得見外部變量,因為只有一個堆。
對比一下今天真寫出來的多線程代碼:把heavy函數源碼字符串化,塞進blob里eval,祈禱它別閉包、別引用import進來的東西、別用到外部定義的類——它已經是字面量了。出錯時拿到的還是ErrorEvent,不是拋出的值。而這次的分支只要new Thread(heavy, input).join(),閉包看得見你的import和類,異常也會帶著真實堆棧飛回來。
并行map的寫法直接改了畫風。加載10萬個對象,八個線程共用一個共享數組和一個原子計數器Atomics.add(next, "i", 1),循環競爭索引、原地寫結果,最后挨個join。沒有消息構造,沒有序列化開銷,讀寫全在同一個堆上。這大概就是作者所說的“把函數扔到另一個核心上執行”——worker從未做到的事。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.