5

メイン メモリに格納するには大きすぎるファイルでディスクに格納されているデータがあります。

次のように、このデータを を介してディスクからデータ処理パイプラインにストリーミングしたいと考えていますiconv。

zcat myfile | iconv -f L1 -t UTF-8 | # rest of the pipeline goes here

残念ながら、データを出力する前に、ファイルが使い果たされるまで、iconv がファイル全体をメモリにバッファリングしていることがわかります。これは、メモリ フットプリントが最小であるパイプラインでのブロッキング操作で、すべてのメイン メモリを使い果たしていることを意味します。

次のようにiconvを呼び出してみました：

stdbuf -o 0 iconv -f L1 -t UTF-8

しかし、iconv 自体が内部的にバッファリングを管理しているように見えます。これは、Linux パイプ バッファとは関係ありません。

これは Arch Linux の gblic 2.6 と 2.7 に同梱されているバイナリで見られ、Debian の glibc 2.5 で削除しました。

これを回避する方法はありますか？ストリーミング文字変換が単純ではないことは知っていますが、このような一般的に使用される UNIX ツールはストリームでも機能すると考えていました。メイン メモリに収まらないファイルを操作することは珍しくありません。にリンクされた独自のバイナリをロールバックする必要がありlibiconvますか?

4

1 に答える 1

2

iconv_openを使用したiconv（3）呼び出しについて考えてみます。これらの2つの呼び出しに単純なCルーチンをフックします。stdinから読み取り、stdoutに書き込みます。この例を読んでください：

http://www.gnu.org/software/libc/manual/html_node/iconv-Examples.html

この例は、あなたが説明していることを処理することを明確に意図しています。-「ステートフル」なデータ待機を回避します。

于 2013-01-23T04:40:11.373 に答える