北京
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.
