ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Sebastien Tandel <sebastien@xxxxxxxxx>
Date: Tue, 06 Mar 2007 20:48:33 +0100
Hi all,

>> 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
>   
as well as the ability to compile minimalistic wireshark/tshark.
I think it could be included (parallelized) in the same project since
one part would be to review all the dissectors.

> 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.
>   
Don't you think it could be better to create a new branch in the svn and
create a long term project?
We could begin this project by inserting a minimal set of dissectors
(and therefore eliminating some of the useless dependencies between some
dissectors) in the new svn branch. Then modify them to be thread-safe.
Once this is done we can continue by adding the others dissectors one by
one into the new branch and modify them.

Of course it requires some extra work to integrate the future patches
coming for the main branch but, IMHO, it would be cleaner.

What do you think?



Regards,
Sebastien Tandel