["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

As someone that has actually studied the feasibility of making
wireshark multithreaded and what would be required

"... Written with tons of globals variables, non thread safe, ..."


There are some global variables in the bulk of the codebase, i.e. the
dissectors. There is actually not that many of them, but that is an
irrelevant point when it comes to multithreading.

This is the least and the most insignificant of issues that prevents
wireshark from being multithreaded.


The real issues are that virtually all interesting protocols are very
stateful which enforces a pure sequential scan and dissection of
packets.

While it would be theoretically possible to make wireshark
multithreaded this would require a massive amount of work to identify
all instances and all protocols (most of them) where you just have to
manually track state and decide when dissection must pause and wait
for previous packets to first be completely dissected before
dissection can resume.

Removing all global variables would be a small effort which would be
interesting but pointless since this is not what prevents
multithreading.


Example :  RPC protocols:
In most RPC protocols it is impossible to even dissect reply packets
at all unless you have first dissected and kept state
remembered from when you dissected the previous request packet.


While feasible it would be an enormous amount of work (but it would be
possible).
Most people such as myself have only single cpu hosts to build
wireshark on which means the interest in working on adding
multithreading (or being able to even test it) is minimal.



I.e.   global variable are not a problem, nor relevant.




On 11/7/06, frederic heem <frederic.heem@xxxxxxxxx> wrote:
> On Monday 06 November 2006 11:16 pm, Ulf Lamping wrote:
> > bugzilla-daemon@xxxxxxxxxxxxx wrote:
> > > Please do not confuse the bug that I may have introduced, and the
> > > wireshark/glib bugs.
> >
> > THERE ARE NO WIRESHARK BUGS THAT YOU'VE FIXED (beside some very
> > unimportant memory leaks)!!!
> >
> and some uninitialized variables, use of stale pointer and stale file
> descriptor ...
> They are not unimportant or important memory leak, they are all leaks that
> needs to be fixed.
> > There are "crashes" in the dumpcap code as you've not used it as
> > designed. Then you've fixed the newly occuring problems at the wrong
> > places.
> A robust a software is a software that can be modified and enhanced without
> collaping like a card castle. Wireshark is everything but robust.
> >
> > Randomly setting a pointer to NULL somewhere in the code and waiting for
> > the program to crash would show exactly the same problems.
> >
> > I won't give you any further examples as I will only get in return that
> > the WS code was badly designed before and there are bugs in other pieces
> > of the code that needs to be fixed for your code to run.
> >
> I kindly ask you where are the bug you find, the only response is the
> complain
> about the some pointer has been tested, some pointer that has been set to
> NULL after being freed !
> These are not bugs but is an effort to make wireshark more robust and less
> error prone. What's wrong with that ?
>
> > > Where are the bugs you find that are not related to glib ?
> > > Could you explain me why you treat the code as "buggy by design" ? Be
> > > constructive and propose something better.
> >
> > I was constructive several times and only got the response that you
> > disagree with my (and other core developers) points of view.
> >
>
> > With "buggy by design" I mean that you seem to simply ignore how the
> > code was written before,
> > partially fix problems introduced by your own changes and then complain
> > that the Wireshark code needs to be fixed.
> >
> Written with tons of globals variables, 2000 lines functions, non thread
> safe,
> pointer not tested, memory leak, uninitialized variables etc.... A weekly
> update due to multiple vulnerabilities.
> > I just don't want to spend any more time discussing on that level,
> >
> > Regards, ULFL
>
>
> ______________________________________________________________________________
>
> --- NOTICE ---
>
> CONFIDENTIALITY - This  email  and  any  attachments  are confidential and
> are
> intended  for  the  addressee  only.   If  you  have  received this message
> by
> mistake,  please  contact us immediately and then delete the message from
> your
> system.  You  must  not copy, distribute, disclose or act upon the contents
> of
> this email. Thank you.
>
> PERSONAL DATA PROTECTION  (Law  by  Decree  30.06.2003  n. 196) - Personal
> and
> corporate  data  submitted  will  be used in a correct, transparent and
> lawful
> manner. The data collected will be processed in paper or computerized form
> for
> the performance of contractual  and  lawful  obligations  as  well  as for
> the
> effective management of business relationship. Data may be disclosed, in
> Italy
> or abroad, for the purpose above mentioned to third  parties  which
> cooperate
> with Telsey, agents, banks, factoring companies,  credit recovering
> companies,
> credit  insurance  companies,  professional  and  consultants,  and
> shipping
> companies. In relation to the same purposes, data  may  be  processed  by
> the
> following  classes  of  executors  or  processors:  management;
> administration
> department; logistics  and  purchase  department; sales department; post
> sales
> department quality department; R&D department; IT department; legal
> department.
> The  data  processor  is  Telsey S.p.A.  The data subject may exercise all
> the
> rights set forth in art. 7 of Law by Decree 30.06.2003  n. 196 as reported
> in
> in the following link http://www.telsey.it/privacy.jsp.
>
> ______________________________________________________________________________
> 798t8RfNa6Dl8Ilf
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev