Well, I don't completely agree with that. You guys only pointed out one
situation (dissecting packets in parallel where there is dependency
between packets) where we cannot use multi-threading, but you cannot
exclude other possibilities. Something like for example parallelizing
some long operations like filtering, statistic calculation. This can be
extremely useful when ethereal need to deal with very big traces. We can
implement a parallel thread that perform the analysis (calling the
dissecting functions) and at the same time still give the user the
control to view the content of one packet (GUI not blocked waiting for
the result).
That was just an example...
... but I see the problem: we cannot deal with all those packet
dissectors that are non-reentrant, so making Ethereal multi-thread is
out of th e question for now...
Perhaps adding few lines on the documentation reminding developers to
make sure the packet dissector is reentrant is a good starting point.
Fabrizio
ronnie sahlberg wrote:
You are absolutely right.
Many protocols are very stateful and it is sometimes just not possible
to dissect the content in paxket x without first collecting some
knowledge from packet x-y .
Example: LSA protocol is not possible to decode until one first has
seen the prior DCERPC BIND command.
Similar dependencies exists for h323 (which i know andreas is familiar
with) and many other protocols as well.
Parallell dissection of packets is theoretically possible but is much
much more difficult than just making all protocol dissectors threads
safe.
On Tue, 5 Apr 2005 08:57:16 +0200, Andreas Sikkema
<andreas.sikkema@xxxxxxxxxxxx> wrote:
ethereal-dev-bounces@xxxxxxxxxxxx wrote:
The question can be rewritte into: does Ethereal call the dissectors
only from one thread at the time or there's a chance (or will be a
chance in future versions) that more than one thread will call the
dissector function at the same time?
What is the advantage of having multithreaded dissection? Parallel
processing of subsequent frames is a sure way of introducing
problems when frame X+1 depends on information from frame X.
Multithreading the rest of the application is another matter of course.
--
Andreas Sikkema Rits tele.com
Van Vollenhovenstraat 3 3016 BE Rotterdam
t: +31 (0)10 2245544 f: +31 (0)10 413 65 45
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
