現状 When compressing, if more than I<timeout> milliseconds (a positive integer) has passed since the previous flush and reading more input would block, all the pending input data is flushed from the encoder and made available in the output stream. This can be useful if B<xz> is used to compress data that is streamed over a network. Small I<timeout> values make the data available at the receiving end with a small delay, but large I<timeout> values give better compression ratio. は 圧縮時に、前回分のフラッシュ処理が行われて次の入力読み込みがブロックさ れ、I<timeout> に指定されるミリ秒以上が経過すると、処理中断していた入 力データがエンコード処理からフラッシュされて、出力ストリームでの利用が 可能になります。こういった処理は、B<xz> がネットワーク越しにストリーム されたデータを圧縮する際に活用されます。I<timeout> に小さな値を設定し ておくと、受信したデータの最終分を利用する際に、わずかな遅延を起こすも のとなります。もっともこの I<timeout> に大きな値を設定しておけば、高圧 縮率が得られます。 なっていますが、最初の所は 圧縮時に、前回のフラッシュ処理からI<timeout>ミリ秒(正の整数)を超えて経過し、 それ以上の入力を読み取るとブロックされる場合、保留中のすべての入力データが エンコード処理からフラッシュされて、出力ストリームでの利用が可能になります。 でどうでしょうか。 flush and reading の and をどう訳するか、なのですけれど。 ここはストリーム圧縮の話なので、データを受け取りつつ圧縮するけれど、 圧縮にはひとかたまりのデータが必要。塊が大きいほど圧縮率は良いけれど 遅延は大きくなる、そこで、一定時間過ぎたら、強制的に圧縮処理を一旦 終了にして、次の処理に移る、ということをしたいと。バッファの関係も あるので、ある一定以上は入力できない。だから、圧縮中は(状況によっては) ブロックしちゃうということもあるから would block かな。 ribbon
Fork