> On Wed, Aug 23, 2000 at 08:22:52AM -0500, Jeff Foster wrote:
> >
> > Can't we treat the secondary passes, to do filters, different and not
reset
> > the visited flag? This has implications in the conversation coding,
they
> > would only be created during the first pass. It may also impact other
parts
> > of the program, but I leave that discussion to others that know more
then
> > I do. It seems to me that this would speed secondary passes up because
some
> > of the work doesn't have to be done for each pass, only the first pass.
>
> I made the change. Here's the CVS entry:
>
> gram 2000/07/25 22:09:00 CDT
>
> Modified files:
> . file.c
> Log:
> When rescanning a file, all state information for the frames has
> been deleted. So we have to set fdata->flags.visited to 0 for
each frame,
> denoting a "fresh" scan.
>
> Revision Changes Path
> 1.201 +5 -1 ethereal/file.c
>
> In rescan_packets(), since the conversations and protocols were
> being re-initialized, (with conversation_init() and init_all_protocols()),
> I had to reset the visited flag. Perhaps we need a change so that
> the application of display filters won't re-initialize the
already-computed
> data, and thus not force a reset of the visited flag.
>
> --gilbert
I'm for anything that will speed up the program. I would like to hear from
others
about the implications of this change -
What will happen if the 'visited' flag isn't reset, and the
conversation_init() and
init_all_protocols() aren't called before a secondary pass through the
packets?
Jeff Foster
jfoste@xxxxxxxxxxxx