On Sat, Feb 28, 2009 at 06:20:35PM +0200, Kalle Olavi Niemitalo wrote:
> Witek, in your commit 4a2fd2d964ef92a10219a3b5e4cce3a8b3be7782 to
> elinks-0.12, you changed BIG_READ from 65536 to 655360.  Was this
> change necessary for bug 1017?  The commit message says you
> cherry picked it from 3131de4767475097eb60bb1641b39e6b647eb289,
> but there is no similar BIG_READ change in that commit.
> A similar change had been made in 0.13.GIT as part of bug 1008
> (uploading big files), which has not been fixed in elinks-0.12.
> However, it seems the BIG_READ change in bug 1008 was actually
> an accident; bug 1008 was intended to affect only POST requests,
> not decompression.
> Commit b8b54a53259ea15014d7595e0f9e1475ae4aecf1 is where I merged
> the bug 1008 changes to ELinks 0.13.GIT.  In those changes, you
> originally gave BIG_READ an additional meaning: how large blocks
> ELinks should read from a file that it's streaming to a server.
> At the same time, you changed it to 655360, perhaps to make
> uploading faster.  However, I then added read_http_post() and
> made both HTTP and CGI use it, and that function does not use
> BIG_READ any more.  Instead, its callers provide a buffer of size
> Thus, it seems BIG_READ has been changed from 65536 to 655360 in
> elinks-0.12 and master for no reason.  This consumes more memory
> than before but I guess users can afford that nowadays.  However,
> I worry that the large value can perhaps hide bugs in the
> decompression code.  I mean, perhaps there is some bug that
> occurs only when the compressed or decompressed data is over
> BIG_READ bytes long.  If BIG_READ were smaller, then any such
> bugs would be easier to find.

655360 is a bit too large, perhaps.
The size of the pipe under Linux is 65536 bytes.
The decompression is started when the pipe is full.
Perhaps, 65536 * 4 for BIG_READ would be enough.

elinks-dev mailing list

Reply via email to