問題タブ [io-buffering]

C++ で cin バッファをクリアするにはどうすればよいですか?

この投稿によると、 std::cout は\n、対話型デバイス (ターミナル ウィンドウなど) に接続されると、自動的にフラッシュします。.flush()それ以外の場合 (たとえば、ファイルにパイプされる場合)、完全にバッファリングされて動作し、またはでのみフラッシュされstd::endlます。

Microsoft Visual C++ でこの動作をオーバーライドして、完全にバッファー モードにするか行バッファー モードにするかを選択できるようにする方法はありますか?

同僚のためにダウンロード ライブラリを作成しました。ダウンロードしたデータをファイルに書き込みます。

私の同僚は、100 Mb のデータがダウンロードされたとしても、ファイルが長時間小さいままであることを発見しました。

したがって、これらのデータをバッファリングするためにメモリを消費しないようにflush()、毎回呼び出す必要があることを示唆しています。write()

しかし、私は 100 Mb の仮想メモリが多くあるとは思いませんし、おそらく Windows には大量のデータをバッファリングする理由があると思います。

あなたはそれについてどう思いますか？

このコードが実装ごとに異なる動作をする理由がわかりません。

CLISPでは、プロンプトが出力されてから読み取りが続くという期待どおりに動作しますが、SBCLでは、読み取りを行ってから出力します。私はインターネットで少し読んでそれを変更しました：

これも、CLISPでは正常に機能しますが、SBCLでは、読み取りを行ってから出力します。私はそれを別の関数に分離しようとさえしました：

そして、それはまだ読み取り、そして出力します。私はforce-output正しく使用していませんか、それともこれはSBCLの特異性ですか？

3秒ごとに既存のファイルに新しい行を追加するPerlスクリプトがあります。また、そのファイルから読み取るC++アプリケーションもあります。

問題は、スクリプトが完了してファイルハンドルが閉じられた後、アプリケーションがファイルの読み取りを開始することです。これを回避するために、各行の追加後にフラッシュしたいと思います。どうやってやるの？

現在、FCGIハンドラーでSinatraアプリを実行しています。ラックアップファイル内（おそらくSinatraアプリの前）に配置され、大きなファイルのアップロードをソケット経由で（最初にディスクにバッファリングせずに）別のサーバーにストリーミングし、リクエストと連動して実行するハンドラーを作成したいと思います。だから私がやりたいのは、パラメータを準備せずに、ある種のストリーム-デコード-送信ワークフローです。Railsチームがミドルウェアパイプラインを見たいという方法のために、Rack内のすべてのアップロードが巻き戻し可能になっているため、これに問題があることをどこかで読みました。これは、アップロードがバッファリングされることを意味するため、提供できないだけではありません。アップロードはRack内で進行しますが、ファイルをディスクにバッファリングしてからダウンストリームに送信する必要もあります。

WebサーバーのリクエストループをRackレスポンダーに結び付け、入力の巻き戻しを強制しない（そして、絶対に愚かな狂気であるアップロードのメモリ内バッファリングを強制しない）クロスバックエンドソリューションはありますか？この種の問題に対する現在のアプローチは何ですか？

RubyではIOバッファリングはどのように機能しますか？IOおよびFileクラスを使用する場合、データはどのくらいの頻度で基になるストリームにフラッシュされますか？これはOSバッファリングとどのように比較されますか？処理のために自信を持って読み戻す前に、特定のデータがディスクに書き込まれていることを保証するために何をする必要がありますか？

Java のスキャナーに問題があります。System.inこのデータに基づいてオブジェクトを解析および作成するメソッドがあります。しかしScanner、メソッド内で作成する場合、それを行うには 2 つの方法があります。つまり、閉じる方法と使用しない方法です。最初のケースでもScanner.close()閉じSystem.inます。そうしないと、事前にバッファリングされ、バッファリングされた文字は別のスキャナから到達できなくなります。Scannerそのため、インスタンスをメソッドに渡します。ただし、コンソールから別のオブジェクトを読み取る必要がある場合は、信頼できませんBufferedReader。さらに、それは本当にきれいな設計ソリューションではないようです。

非常に大きなASCIIファイルを「マップ」しようとしています。基本的に、特定のタグが見つかるまで行を読み、そのタグの位置を知りたいので、後でもう一度検索して関連データを引き出すことができます。

今、これtellは私に正しい位置を与えません。この質問は、以前にさまざまな形で尋ねられました。その理由はおそらく、python がファイル オブジェクトをバッファリングしているためです。したがって、python は、ファイル ポインタがどこにあるかではなく、ファイル ポインタがどこにあるかを教えてくれます。 このバッファリングをオフにしたくない... ここでのパフォーマンスは重要です。ただし、python がバッファすることを選択したバイト数を決定する方法があるかどうかを知っておくとよいでしょう。私の実際のアプリケーションでは、 で始まる行を閉じていればFoo問題ありません。あちこちに数行をドロップできます。だから、私が実際にやろうとしていることは次のようなものです：

バッファサイズを見つける方法はありますか?

この質問に触発されて、Python のopen()関数に対するオプションのバッファリング引数が何をするのか正確に知りたいと思っています。sourceを見ると、ストリームのバッファサイズを設定するためにbufferingが渡されていることがわかります(ドキュメントで確認されている のないシステムでは何もしません)。setvbufsetvbuf

ただし、ファイルを反復処理する場合、READAHEAD_BUFSIZE一度に読み取られるデータの量を定義するように見える と呼ばれる定数があります (この定数はここで定義されています)。

私の質問は、buffering議論が にどのように関係しているかREADAHEAD_BUFSIZEです。ファイルを反復処理する場合、一度にディスクから読み取られるデータの量を定義するのはどれですか? そして、これを明確にする C ソースの場所はありますか?