Clojure core.async go-blocksはいつ便利ですか？

Question

go-blocksを実行しているスレッドプールはかなり小さいので、go-blocks内のいくつかの操作はお勧めできません。たとえば、blocking I/O is badを実行して、計算量の多い操作を行うことは悪いです。いくつかのそのような操作がgo-blocksで実行されると、スレッドプール全体が繁殖し、他のgo-blocksはまったく実行できなくなります。

Clojureプログラマは、最も一般的なシナリオとしてどのようなブロックを使用していますか？これは、すでに非同期ライブラリでの作業に主に役立つのですか？ライブラリ/コードを使用してより美味しいチャンネルの変形にコールバックを変換しますか？私は非常に興味があるでしょうが、実際に駐車場の操作で行くブロックがスレッドよりも好ましい場合があります。

Answer 1

つまり、core.asyncチャネルを非同期クロージャアプリケーションで使用する場合は、goブロックを使用します。

core.aysncには、「いいえ、私たちはすでに忙しいので新しい労働者を作成しません」という仕組みが備わっています（つまり、100000 goブロックを作成するとシステムは破壊されませんが、スレッドで自宅でこれを試してください、または無制限のキューを持つスレッドプール）。これは大きな勝利であり、これを自分で行うためにスレッドを同期する必要がなくなります。バックプレッシャを必要とする問題（プロデューサやコンシューマの問題など）は、このモデルによく適合し、core.asyncは最適な選択です。

しかし、goマクロはclojureコアライブラリの一部ではなく、並行性を実現する汎用ツールとして使用することを目的としていません。その目的は、非同期コードを抽象化してより同期的な方法で流すことです。あなたのユースケースを考慮して、モデルが適合すれば、それに行ってください！

Answer 2

スレッドごとに最低限のメモリ（default 1MB on 64-bit linux）が必要です。平均的なコンピュータでは数百スレッドは問題ではないかもしれませんが、数千以上のメモリで多くのメモリを消費することがあります1GB以上のメモリ）。また、スレッドがブロックされている（実行されていない）場合でも、これらのリソースは消費されます。

時間の1〜10％しか実行していないタスクがあるとします。通常のスレッドを使用すると、必要以上に10倍から100倍のリソースが消費されます。 goブロックは「パーキング」を介してスレッドを共有するため、10倍から100倍のスレッドリソースを削減できます。これが利点です。

2番目の利点は、core.asyncをClojureScriptで使用してブラウザで実行できることです。 CLXSがコンパイルするJavaScriptは単一のスレッドしか持たないので、通常のJavaスレッドが利用できない場合でも、core.asyncはブラウザでマルチスレッドのように錯覚することができます。