概要
WHATWG Streams のことを何回かに分けて書く。Kyoto.js #11 の『 WHATWG Streams をためした 』という発表のために調べたものだ。発表だけで終わらせるのはもったいないので、再整理して共有する。
前回は『 WHATWG Streams の Source と Sink - Qiita 』。今回は Lock のことを書く。
Lock
- ReadableStream (以下 RS) / WritableStream (以下 WS) には Lock 状態がある
- RS / WS の Reader / Writer が確保されているとき、Lock される
- Lock されると、他の Reader / Writer は RS / WS を読み書きできない
- RS / WS の
get locked(): booleanで Lock されているかを確認できる - ぼくは Node.js Stream とは大きく異なる点だと思う
- 比較は stream between nodejs and whatwg を参照
RS の読み取り操作
-
pipeTo(writable: WS): Promise<void>…… WS に pipe -
pipeThrough(transform: TS): RS…… TS に pipe -
tee(): [RS, RS]…… RS を分岐 -
getReader(): Reader…… 上 3 つの内部から呼ばれる低レベルな操作
すべての読み取り操作は getReader() につながる。そして getReader() は Lock を確保する。
Reader
- Reader は RS の internal queue を dequeue できるもの
-
getReader()でその RS の Reader を確保できる - ひとつの RS につき、同時にひとつの Reader しか確保できない
- おそらく複数 Reader での読み込みによる漏れを防ぐため
- Reader を開放することで新たな Reader を確保できる
- ぼくは「
getXXX()が破壊的な操作ってどうなのよ」と思う
WS / Writer
RS と同様。