独自の非同期関数で core.async の機能を拡張することは推奨されますか?
チャネルの非同期性は、コールバックを受け入れるput!
およびによって処理されますが、プロトコルは名前空間take!
にネストされています。implは近づかないことを意味async.impl.protocols
しますか?この場合、またはそれらを実装しても大丈夫ですか?
たとえば、Netty チャネルまたは Java ソケットを ReadPort および WritePort としてラップできます。
独自の非同期関数で core.async の機能を拡張することは推奨されますか?
チャネルの非同期性は、コールバックを受け入れるput!
およびによって処理されますが、プロトコルは名前空間take!
にネストされています。implは近づかないことを意味async.impl.protocols
しますか?この場合、またはそれらを実装しても大丈夫ですか?
たとえば、Netty チャネルまたは Java ソケットを ReadPort および WritePort としてラップできます。
プロトコルの意図は、core.async
独自のバッファ、チャネル、ポートなどを実装するための実装フックとして機能することです。それらはパブリック ユーザー API ではなく実装の一部であるため、impl の下に存在します。
チームは、ライブラリのアルファ版以外のバージョンがリリースされるまで、それらを変更できると考えています (時間枠はありません)。async のリリースから現在に至るまで、プロトコルは変更されていませんが、現時点では特に と のプロセスに重大な変更がput!
ありtake!
ます。
今のところ変更のキャッチに対処する意思がある場合は、自由に実装してください。
Tim B は、非同期チャネルをネットワークに接続することにかなりの時間を費やしましたが、チャネルのセマンティクスを維持しながら行うのは非常に困難です。これに対する現時点での推奨パターンは、ネットワーク I/O と通信し、アプリケーション内のチャネルと「エッジで」通信する専用スレッドを使用することです (おそらく と を使用put!
しますtake!
)。このパターンでは、内部プロトコルを実装する必要はありません。