ronnie sahlberg wrote:
Feel free to reverse that change.
If time permits, I'll try to improve this.
It was part of an effort to start refactoring the code so that it
would eventually become possible to multithread wireshark, but the
work required to implement everything required is just too massive to
be realistic.
Well, my feeling about this is that this goal is a huge amount of work -
unrealistic for a single person - but maybe not unrealistic for the
whole devel team.
The requirements that arise from the horizon seems to be pointing in
that direction:
- loading multiple files into one Wireshark instance
- make use of multitasking "Core" processors while loading capture files
I would *love* to see this change, although I agree this will be a huge
amount of work.
In the background of the huge amount of dissectors we have nowadays, the
only way to achieve this is to work step-by-step.
As almost every dissector will be involved, the only realistic approach
in my eyes would be an approach I would call "blooming". The "changed"
dissectors will exist for a long time in parallel to the "old"
dissectors. The "blooming" approach means we'll have to "bloom" from the
bottom to the top (e.g. Ethernet to HTTP) - while the Ethernet dissector
is already thread safe, the upper IP/TCP/HTTP dissectors are still "old
style".
This means the supporting libraries will have to have two sets of API
calls, the new thread safe and the old "classic" one.
I don't know if there's enough motivation in the community to follow
this approach - to bring this task to a real life ...
Regards, ULFL
