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 > POST_BUFFER_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. Witek _______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
