15:27雑なことを書くと誤解を招きかねないんで正直書くかどうか迷ったんだけれども。使う機会に恵まれて(?)、そういえば、と。本題に入る前に、「誤解を招きかねない」へのガードのための「そもそも論」から。使う」ことの是非から検討すべき、てことは最初に言っておかないといけない。何か「重たいコア処理」と「それに依存するタスク」のペアがある場合、考えることは、「その2つをどのように分離して連携するか」である。ない限りは実際のデータ送受が発生する。モジュールを利用出来るが、ここでのデータ連携はプラットフォーム依存だが「プラットフォームがサポートするプロセス間連携のインフラ(セマフォなど)」を使う。モジュールが候補から外れるケースは、非常に当然のことだが、「重たいコア処理」と「それに依存するタスク」に明確な親子関係を持たない場合、持たせたくない場合であり、つまりは「重たいコア処理」を「サービス」として独立させたい場合である。socket」はお呼びではない。いう大前提を踏まえた上で...。recvexactly」の話。ないよ、実在してない。常識かなとは思うけれど。そのことで必要になるたびに「ちょっとは鬱陶しいなぁ」とは感じてはいたんだけれど、あまり深い考察は試みたことがなかったんで、ちょうどいい機会かな、と思って。ええやん」と決断したとしたら、次にすべきことは、「プロトコルを考える」ことである。プロトコルも考えなければならない。「データ終端」の扱いのことを言っている。ない」ことが問題になるのは「送受信サイズを予めやりとりする」プロトコルを選んだ場合だけである。バイトを「取れないなんて何事だ」、てことになる。ないなら終端発掘するまでループすることには何の抵抗もあるはずがない。いつだって期待通りに振舞う。たびに例えば「update」だとか「feed」に逐次渡していくことは大変合理的である。お呼びではない」のな。標準モジュールのあり方としては、実際に提案・検討されたことがある。へはこの質問から辿りついた。どちらでも、「別にいらんのでは」ていうワタシとおんなじことを言ってる人もいるし、本家で話がストップしている理由の大きなものはやはり「期待通りのデータが得られぬまま」だった場合のエラーの扱いが繊細なこと、みたいだね。bytes(buffer)これが仮に適用されていたとすればまぁ「ありがたく使おう」という状況も「皆無ではない」とは思うけれど、ここまで考えてきた通り、実際はこうやって「バイトの塊の全部をバイト列で返してくれる」ことそのものが「大きなお世話となるケースが多い」のであろうなぁ、と。「ビジターパターン」的に、利用者側に割り込める余地があるものならありがたい可能性が高い。ない」ことの唯一の実害は、「使いたいときにそれがない」ことではなくて、「いずれにせよループして全部を食べ尽くすコードを書く必要があるが、毎度忘却してて最大5分くらいは頭を掻き毟る、かもしれない」てことでしかないわけね。似せた自前処理」を書くわけだから、その「元ネタの有無」でしかないのだろうなぁと。別にあって困るもんではないと思うわけで、つまりは「あるので非」てことは絶対にない。16:40追記:すまん、書くつもりで忘れてた。recvexactly」がなくても困らない。