Wireshark-dev: Re: [Wireshark-dev] Ronnie's SVN 20251 looks quite strange to me - is there a reason?

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 06 Mar 2007 00:27:12 +0100

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