Re: [Wireshark-dev] Enabling threads by default
I would be extremely careful with pcap_compile. Last time I checked the sources. pcap_compile was not thread safe (because internally it uses global variables), so you would need to use synchronization to protect concurrent calls to that function. Have a nice day GV -Original Message- 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 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 I'm aware of is that you shouldn't use GDK (and therefore most GTK+) routines on Windows: http://developer.gnome.org/gdk/2.24/gdk-Threads.html However, this shouldn't apply to stat() or pcap_compile_nopcap(). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Enabling threads by default
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 I'm aware of is that you shouldn't use GDK (and therefore most GTK+) routines on Windows: http://developer.gnome.org/gdk/2.24/gdk-Threads.html However, this shouldn't apply to stat() or pcap_compile_nopcap(). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Enabling threads
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 consuming :-) > > 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. > Are you already working on this? I had a look at the cygwin setup program, as they (depending on a user setting) use the internet access from Internet Explorer to load files from the internet. That has the great advantage that this is working well with a proxy, if the proxy settings of IE is set correct. I've also started to write a proposal how a file content could look like to update things - it needs some more polishing before I'll send it to this list (to reduce a lot of discussion by providing a clean proposal the first time). My thought was also to use the syntax of the preferences file :-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Enabling threads
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@wireshark.org >>> http://www.wireshark.org/mailman/listinfo/wireshark-dev >>> >> ___ >> Wireshark-dev mailing list >> Wireshark-dev@wireshark.org >> http://www.wireshark.org/mailman/listinfo/wireshark-dev >> > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Enabling threads
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Enabling threads
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 <[EMAIL PROTECTED]> 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@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Enabling threads
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@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Enabling threads
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 http://www.wireshark.org/mailman/listinfo/wireshark-dev
