STREAMS
Basic Concept
STREAMS 是 UNIX System V 提供的一套 I/O 框架，概念是讓 user process 和 device driver 之間的資料處理可以模組化——你可以把不同的處理邏輯像積木一樣串在中間，動態組合成一條 pipeline，而不是把所有邏輯都塞進 driver 裡。
常見的使用場景是 terminal 輸入輸出、網路 protocol stack 這類需要多層處理的地方。一個 stream 就是 user process 和 device driver 之間的一條雙向通道，雙向的意思是資料可以同時往兩個方向跑：user 寫資料給 driver，driver 也可以同時把資料送回給 user，兩邊不會互相卡住。
Structure
一個 STREAMS pipeline 包含：
- Stream head：接 application system call 的端點
- Driver end：控制底層 device 的端點
- Stream modules：插在 stream head 和 driver end 中間的可堆疊 modules
每個 component 都有兩個 queue：
- read queue：資料往 user process 方向流。
- write queue：資料往 device 方向流。
資料在相鄰 modules 的 queues 之間以 messages 傳遞。
Why STREAMS Exists
傳統 character-device I/O 常被當成 unstructured byte stream。但在 terminal、network protocol、driver processing 中，資料常需要經過多層處理，例如 line editing、packet framing、protocol transformation、control message handling。
STREAMS 的目的，是讓這些處理能被拆成可重用 modules，並在 runtime push 到 stream 上。Application 可以透過 ioctl() 把某個 module 加到 stream pipeline 中。
Data Flow
Flow Control
Queue 可能 overflow，因此 STREAMS 支援 flow control。若下一個 queue 沒有足夠 buffer space，支援 flow control 的 queue 可以暫停接受或傳遞 message
但 driver end 面對真實 device event 時不能永遠阻擋 incoming data。例如 network card buffer 滿了，device 可能只能 drop incoming packets，直到有空間。
Blocking Behavior
STREAMS 內部的 I/O 通常是 asynchronous / nonblocking 的，因為 message 在 modules 之間排隊傳遞。但 user process 和 stream head 溝通時仍可能 block：
- write 時，如果下一個 queue 因 flow control 沒空間，process 可能 block。
- read 時，如果沒有 data available，process 可能 block。