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 well with GTK+ 2.4,
it looks like that's still the case and won't change any time soon. The
threads section of the GDK reference on developer.gnome.org says:
"Unfortunately the above holds with the X11 backend only. With the Win32
backend, GDK calls should not be attempted from multiple threads at all."
There's also a bug entry at
http://bugzilla.gnome.org/show_bug.cgi?id=60620 that's been marked
WONTFIX with the recommendation of using idle/timer callbacks instead of
threads for display code.
LEGO wrote:
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 redraw one that causes a significant
overhead.
However, wouldn't be better just fork the upgrade agent?
On 11/8/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
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 which is why it was removed :-(
On 11/8/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
Gerald Combs wrote:
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.
Sorry, but I don't really understand the relationship - can you explain
what you mean?
When I remember correct, the threading support wasn't working well with
GTK2.4, but that might have changed since then.
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev