Latent bug in the new tradindexed code?
rra at stanford.edu
Tue Sep 17 15:40:49 UTC 2002
Alex Kiernan <alexk at demon.net> writes:
> I've a different problem I'm trying to get to the bottom of, but I
> came across this en-route - I think the new tradindexed code is
> breaking the assertion its making wrt OVSTATICSEARCH.
> AFAICT returning false from OVctl(OVSTATICSEARCH,...) says that the
> buffers you are returning are constant up until OVclosesearch(), but
> the new tradindexed code can remap the data file which would break
> this assertion.
I assumed that returning false to OVSTATICSEARCH meant that one's search
wasn't static. *heh* You're correct that it can remap the data file.
> I think it should probably set OVSTATICSEARCH to true, but actually I'd
> really like to just remove OVSTATICSEARCH, rip out the whole mess which
> surrounds it in article.c, since I'm really not convinced that much
> complexity is worth saving a copy.
The right way to avoid the copy, if someone really cares, is to provide an
interface to the overview API that says "here's a range, here's a file
descriptor, spew overview information from that range down that file
descriptor." That'll be the fastest since if the overview information
happens to all be sequential, you can even use sendfile.
I'm not sure how much we'll get hurt by the memory allocation (I'm more
worried about that than the copy). It would be useful if the interface to
OVsearch were changed; I'd rather pass in something that looked more like
the struct article that tradindexed uses internally, but with a struct
buffer to hold the overview information for overview methods that have to
copy. That way, if you have to copy, you at least don't have to do a
But failing that (which is a lot more work), I'm inclined to agree with
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers