tarosukeの日記: 非同期処理 2
日記 by
tarosuke
これの続き。
やっぱり非同期処理はダメだ。実際に非同期APIや非同期構文で何か書くのを想像してみればわかる。非同期なリクエストを発行してから結果を受け取るまでの間には発行したリクエストに関する処理は書けないからだ。つまり、どう考えてもそこには無関係な処理しか書けないために処理が無駄に汚くなる。
それでも結果をイベントとして受け取るようにするとリクエスト発行後は一旦終了という形になってだいぶ綺麗になるものの、今度は発行と結果が分離して処理が細切れになってしまう。何にせよこれらはカーネルなしでそれなりに処理を回すための方法(大昔にはよく使ったなぁ...)であり、スレッドをきちんと扱えるシステムでこれをするのはナンセンスだ。
更に「処理が待ちになったら即座にCPUを明け渡す」という原則にも反し、システム全体のパフォーマンスを悪化させる可能性もある。もしこれを言語レベルでやってしまうとカーネルにCPUを返せなくなってしまい、無駄にCPUを食い潰す事になる。またカーネルのAPIを呼ぶようにするとその言語は特定のカーネルに結び付く事になり、他のシステムでは使いにくくなる。
なので非同期APIも非同期処理のための構文もすべからく避けるべきだよ。
記法設計の問題 (スコア:1)
例えば、 で、hoge, huge, hage が非同期的な何かである場合、このようにかける利点は結構あるかと思います。
私の場合、大抵非同期的処理を設計する場合には、あるインスタンスのある処理が別の処理に依存する場合には、自動的に依存性のある処理を待機するようにさせます。
(CPU でも、昔の RISC を除いて、普通のプロセッサはそのように動作しますし)
単に、裏スレッドで実行されるにしても、スレッド(新しくスレッドを作成するのか、あるいは既にあるスレッドに処理をスケジュールさせるのか)などを意識することなく、それぞれ最適な実装で、目的の関数や機能を実現できます。
という意味で、かなり上位層の設計にかかることなのですが、私の経験上、上位層で非同期処理がかけるということは、かなり有益です。
特にUI関係では、設計が上手ければ、上位層の記述がかなりスマートになるのではないかと思います。
Re:記法設計の問題 (スコア:1)
resultは同期なのね。そしてhogeはリクエスト投げるだけだから分散処理にもできるわけだ。これはイタダキですぅ(ぉ