Re: Run-time dynamic linking in grep

[Reuben Thomas]

On 30 January 2011 22:22, Jim Meyering <address@hidden> wrote:
> ??
> Odd that you saw it that way.

A faulty assumption on my part.

> Yours converted spaces-to-TAB:
>  http://cache.gmane.org//gmane/comp/gnu/grep/bugs/3455-001.bin

Yup.

> and so did mine (i.e., unchanged from your original):

I wasn't expecting that, and didn't check. I thought you were undoing
my unnecessary change, unnecessarily.

So your patch must have been mangled (as you suggested), possibly by
Emacs's whitespace-mode again (but I didn't think it was on by default
in diff-mode), and it didn't apply to the trunk for me.

Now I understand!

So I'll pay closer attention next time I get a cleaned-up diff from you.

Also, sorry I've not yet made any progress on my patch.

I have however had a possible bright idea.

I got to the point where I was unable to rewind the input stream when
it was a pipe, and hence unable to pass the stream on to the
decompressing veneer functions, because it lacked 5 bytes at the
start.

As per Paul Eggert's suggestion, I said I would try a version of my
patch that fed data into a decompressor process, rather than using the
libraries directly. But this would also solve my problem, as I could
re-inject the first 5 bytes that I'd read to analyze the magic.

So not only does Paul's suggestion look good for improving performance
in decompressing (suitably large?) amounts of data on SMP machines; it
also looks like the only simple way of working with pipes (the complex
way, being, as I already said, to call the low-level decompression
APIs myself, which I don't really fancy).

So, how about I do another cut of my zio veneer library which uses
decompressor processes as well as library calls? I can test
comparative performance, and then worry about whether I can use just
the out-of-process code, or whether some sort of further user
selection is warranted (with a fallback to out-of-process
decompression when stdin is a pipe).

-- 
http://rrt.sc3d.org