On Wed, Dec 04, 2002 at 10:22:17AM -0500, Jason House wrote: > As guy points out, that functionality is still useful... certain taps > rely on a complete edt/proto_tree structure... but the ones that are > most like the originally envisioned functionally would benefit from > getting called immediately. You still don't need queuing for those - they'd be called immediately after the dissection completes. > Also, I believe one of the concepts with the tap listener system was > to allow tap listeners calls to occur in a lower priority thread than > physical packet capture... I think the idea is that tap code that updates the display occurs in a lower priority thread, not code that actually processes the packet data - you can't defer the tap listener calls beyond the point at which Tethereal or Ethereal starts dissecting the next packet, but you can defer display updates. > Guy Harris wrote: > > Passing the epan_dissect_t might not be useful except for tap listeners > > not tapping off of a dissector, as the protocol tree wouldn't be > > complete; those listeners might be called after the entire dissection is > > complete. > > In fact, if a tap listener is called after incomplete dissection and > performs a search by using epan_dissect_t, couldn't that make later > searches for the same item have incorrect results? I believe that edt > caches the results of searches and only performs new searches... What's a "search"?
Powered by MHonArc 2.6.10