這次 Golang 1.22 版本針對內建的 http.ServeMux (HTTP request multiplexer) 進行改善，原本 http.ServeMux 的設計力求直覺單純，適用在架設簡單 HTTP server 的應用場景；但隨著 RESTful API 成為目前 HTTP-based interface 設計主流，而既有的 http.
接續前面文章提及到，在上傳檔案的使用情境之下，因為 user request 數量增多，造成 service lead time 大幅提升的問題；而導致 lead time 增加的因素，根據實驗數據，主要是因為：
在實作檔案上傳並加解密的服務時，遇到了 user request 數量增多，造成 lead time 大幅提升的問題。服務本身是使用 Python + FastAPI framework 實作，在排除了網路頻寬問題和 server 效能問題後，懷疑是 Python 或 framework 導致延遲時間拉長，所以就決定從此地方著手進行 benchmark 實驗，來觀察瓶頸是發生在何處。
自從 2022 年換了新工作，花了蠻多心力在適應工作環境和內容，就先停止更新了 blog。而新工作除了技術之外，我認為自我成長最多的部分應該是跨部門合作溝通、專案時程安排，以及簡報和語言能力等軟實力。其實當時在換工作的時候，就有預期在新的工作崗位上能夠獲得什麼，我想身為資深工程師，技術的持續精進已經是要能自我安排的日常任務，新職位的技術學習已經不是首要考量，反之希望自己能更加強於與人溝通和表達能力這部分。此外，技術學習也從不斷的跟進新技術，轉由能夠判斷當前的情境和預算資源應該要使用怎樣的架構，如何能在滿足使用者需求和時程的安排下將功能完成，並且考慮到不同錯誤和意外處理的情況。
老實說，新工作帶來蠻大的工作壓力，可能也是自我期許比較高，因此這一年花費了非常多的時間在了解公司內部狀況，和如何能將自己的能力正確地發揮在工作崗位。最終在績效表現上， 2022 和 2023 年有蠻不錯的正向回饋，希望新的一年 2024 年也可以繼續朝目標邁進。
Gem5 是針對電腦系統架構所設計的模擬器，目前主要用於系統層面相關的研究，可以模擬出執行所需的 cycle 數、記憶體 access 數、cache miss 等。其中 Gem5 將各組件模擬模組化，並透過 C++ 後端和 python 前端設置的方式來實作，除了可以快速地置換和配置想要的組件之外，也方便研究人員自行新增想要的新設計。這篇文章主要介紹 Gem5 模擬系統運行的機制和相關 configuration 初始化原理。
我們在開發 device driver 或是 embedded system applications 時很常用到 volatile 來宣告定義變數，藉此提示 compiler 此變數可能會被硬體或是 interrupt function 修改，因此當 compiler 進行 code optimization 時，要確保涉及到 volatile 變數的操作不會被更動到。（舉例來說，當 compiler 在進行分析時，發現此變數涉及的操作只有讀取但沒有寫入時，就有可能調整執行順序，以改善程式效能）。雖然這對開發者來說可能是很基本的知識，但我們最近還是踩到了小坑，因此這篇再一次的透過 C11 標準來複習 volatile 定義，並且說明可能會有的疑問。
由於在 crypto subsystem 中預期多個 crypto request 可以同時向同一個 crypto engine 發出請求 ，因此 crypto engine driver 必須實作對應機制，使其有能力能應付此情況。此外，結合在前一節有提到 crypto subsystem 的 asynchronous crypto API 流程，較常見的實作方式就是 crypto queue 搭配 worker，額外開一個 kernel thread 來與 crypto engine 進行溝通，並讓 crypto request 按照 FIFO 順序處理，而本文主要針對此設計方式，說明整個運作流程和細節。
最近踩到 compiler optimization 的一個小坑，gcc5 版本以上，開啟 optimization level 2 時，會將 malloc + memeset 轉換成 calloc。看起來似乎蠻有道理的改善，卻因為我在進行客製化 malloc 時，沒有這注意到這點，導致最後程式執行的是 libc 的 calloc 而不是我的 wrap_malloc。
在 crypto subsystem 中，crypto API 分成 asynchronous (異步) 和 synchronous (同步) 兩種機制。
介紹由應用層所發出的 crypto(cryptography) request，透過 system call 將 request 傳送到 Linux kernel 端，並經由 crypto subsystem 將 request 轉發給硬體算法引擎 (hardware crypto engine) 的流程。