α−1 運作原理 根據註解表示： 在刪除節點時，如果要刪除的節點有右子節點，則刪除過程涉及將要刪除的節點替換為右子樹中遇到的第一個節點(249 ~ 254行)。在這個替換之後，會對新插入節點的右子節點進行更新操作(255行)。 同樣地，如果要刪除的節點沒有右子節點，替換過程涉及利用左子樹中找到的第一個節點。隨後，會對替換節點的左子節點進行更新操作。 在要刪除的節點既沒有左子節點也沒有右子節點的情況下，可以直接從樹中刪除該節點，並對被刪除節點的父節點進行更新操作(282行)。 248 void st_remove(struct st_node **root, struct st_node *del) { 249 if (st_right(del)) {

跟著Jserv老師學習coroutine時，老師在上課期間原本要demo cserv，結果因為使用的server是Aarch64架構而作罷了。小弟我非常膨脹的想，不就是稍微加一點組合語言的雜活嗎？這麼簡單的事我分分鐘就搞定了，於是我就興沖沖地抓code來改，想不到這就是我上班偷懶下班失眠的開始，在此記錄一下。 Code Trace 其實要改的東西也不多，就只是coroutine的context switch從x64換成aarch64的組語即可，其中context_switch跟linux kernel在__switch_to_asm做的事情有87%像。這不就簡單了嗎，只要把kernel中對應aarch64的cpu_switch_to抄過來就完事了，聰明如我抄完之後就出現了以下畫面： 雖然看起來是有在執行，但是我的CPU卻忙到爆炸並且我用wget localhost:8081會直接停住啥屁都看不到，用gdb看起來也好好的看不出問題所在。偷偷回去用x64跑跑看才發現由於我沒有先理解這個專案的行為，所以gdb設定錯誤導致我看不出問題在哪裡。因為此專案會fork出CPU數量的processes，而gdb在執行時預設是追蹤parent process，所以要trace此問題需要set follow-fork-mode child才會看出問題出在child processes執行到一半SIGSEGV。既然知道有Segmentation Fault就可以用backtrace確認是從哪裡走到哪裡死掉的。 //TODO:補關於bt的圖 兜兜轉轉了一圈為了瞭解是怎麼死的還是要看清楚在x86_64架構下是怎麼運作的，下面是我追蹤coro_stack_init一路到coro_routine_proxy後對coro_stack的理解 。 coro_stack

contributed by < LadonYude > GitHub 作業要求 [x] 在 GitHub 上 fork lab0-c參閱 Git 教學和 GitHub 設定指引 ^附教學影片^ [x] 依據上述指示著手修改 queue.[ch] 和連帶的檔案，測試後用 Git 管理各項修改，要能滿足 $ make test 自動評分系統的所有項目。 在提交程式變更前，務必詳閱 如何寫好 Git Commit Message