-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Gerald Combs
Sent: Tuesday, July 12, 2011 8:46 AM
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Enabling threads by default
Is there any reason threads shouldn't be enabled
Is there any reason threads shouldn't be enabled by default at compile
time? Having them available might give us cleaner solutions for bug 3810
(Delay due to stat()ing each recent entry in the main window and bug
5356 (Delay due to DNS when checking capture filter syntax).
The only caveat that
yes.
we used to have 2 threads in the old ethereal for a short period.
one thread for the main application and a second thread that was
dedicated to only update/redraw teh statistics taps once every few
seconds.
this did cause a quite significant degradation in performance/speed of
ethereal
However I believe that what Gerald is talking about is using threads
for asyncronously executing upgrades.
I do not think that the very linking to the thread libraries causes
performance degradation.
If on a single processor you must continiuously switch contexts
between the main thread and the
That's correct. Checking for updates would be pretty easy if we could
connect to the server, issue a request, and feed the response to
read_prefs_file(). It'd be even easier if we could do so from a thread
instead of a separate process.
In regard to Ulf's comment about threads not working
Gerald Combs wrote:
That's correct. Checking for updates would be pretty easy if we could
connect to the server, issue a request, and feed the response to
read_prefs_file(). It'd be even easier if we could do so from a thread
instead of a separate process.
And probably less memory
Is there any reason threads shouldn't be enabled by default? It would
make implementing the version checking and windows update features in
the roadmap a bit easier and cleaner.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
