Webサーバアーキテクチャの基礎知識
Node.js の章に入ると急に饒舌になると思うが、それ以前の章はあくまで教科書的な話しかできないだろう 下の記事を元に
...コードレベルにより踏み込んだ、かつ、green threadベースの新しいWebサーバアーキテクチャも含めて整理された記事... 目次拾い読み
system programming
stream
multi processだと親子でのメモリ空間が分離されるが、multi threadだとしないのでパフォーマンスが良い
コスト：各スレッドで同一リソースにアクセスできてしまう。このracingを避けつつコードを書く必要がある
デッドロックなどの問題が発生したりする
ここは拡張可能
single threadでの非同期処理は時間分割
I/O実行中に待たずに別のタスクを進める
この仕組みでのプログラミングの際には、「Aが終わったらBする」仕組みが必要
ready通知が来たfile discriptorのみaccept()しているので、IOが終わるまでの時間を自由に使える
Receiving an event from epoll_wait(2) should suggest to you
that such file descriptor is ready for the requested I/O
operation. You must consider it ready until the next
(nonblocking) read/write yields EAGAIN
非同期処理はmulti threadでも可能でも可能（1つ1つのスレッドをsingle threadとしてみる）
簡単に説明すると非同期計算をするためにはタスクのキューイングと、そのタスクをコンピュータリソースに割り当てるスケジューラの実装が必要となる。スケジューラやランタイムを提供しているのが Rust だと tokio だ...
実際にはより複雑な次の世代が利用されるらしい
モチベーション：シングルスレッドにしてコンテキストスイッチ自体を無くすのではなく、マルチスレッドでもコンテキストスイッチ自体が小さければいい。OSのスレッドではなく自作する
タスクの消化に村があるのでキューが詰まったりするので空いてるキューにタスクを移す仕組み
理論上green threadにFDの上限はないが、物理上限があるのでnative threadとgreen threadをマッピングする
スレッドを自作する場合に配慮が必要な項目
メモリ中領域にはヒープとスタックがある
スタックを積み上げすぎるとガードページに達してスタックオーバーフローになるようにする
ただしgreen threadを大量に作ることを想定するとガードページ自体がチリツモで無駄になるので、Goはガードページを無くしているらしい
別CPUサポートをしやすくする
参考文献として挙げられている