仕事のお話。
いわゆる非同期処理の話なのだが、あまり僕自身もこの領域は詳しくないので、調べてつつわかったことをアウトプットしてみます。
RPCを利用して処理を実行する場合、何もしないと同期処理となる。
つまりコールをして、結果が返るのを待ち、結果が返ってきたら処理を再開する。
これだと結果が返るのを待っている間は、”待つ”という処理を行うだけなので、CPUを有効的に活用できず非常にもったいない。そこで処理が終わるまで他の処理をさせておき、処理が終わったら結果を取得し、残りの作業をするという”非”同期的処理を行う必要がある。
Ajaxなどでよく利用されるXMLHttpRequestなどは非同期処理を活用しているわかりやすい例だ。
非同期処理のハンドルの仕方には大きく2つの手法がある。
- Futureに代表される、時間がかかる処理に結果をもらえる引換券を渡し、それを任意のタイミングで結果をもらいに行き処理を行うという方法
- CallbackやDeferredに代表される、処理が終わったら実行時にあらかじめ定義した関数を実行する方法
それぞれ長所短所が有るのだが、僕が作ろうとしているものにおいて、それぞれ問題がある。
- Future
結局誰かがFutureを監視する必要がある。 - Callback
非同期処理を行った後さらに別の非同期処理を行い、さらにその後に・・というフローではコーディング・運用両面で大変そう。
ただこれは非同期処理を呼び出すクライアントサイドで、あまり大きな問題にならない。
問題となるのはサーバサイドだ。
たとえばRPCでクライアントからリクエストを受けた後、サーバは別のホストにhttpコネクションを張り、そこから値を取るという処理をしたい場合、それぞれの処理単位で同期的に処理してしまえば楽だろうが、そうすると結局そこでブロックされてしまい、クライアントでブロックされないだけでシステム全体で見たらブロックが発生してしまう。
という問題をどのように解決したらいいか考えているのだが、まだ考え中。
また考えて考えがまとまったらエントリーに上げたいと思います。
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.