Re: [perl-win32-gui-users] Avoid the appearance of a frozen
Thanks for all the great responses! I changed my code so that each GUI handle is managed only by the thread that created it. This works perfect--and has eliminated all the crasing I was seeing! As a follow-up question, how do you know *for sure* which modules are not thread-safe? For example, I wouldn't have guessed that DBI isn't thread safe. Thanks again, Rob - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Avoid the appearance of a frozen
To clarify my earlier comment: DBI is considered threadsafe but some of the DBD's are not. Here's more info: http://search.cpan.org/~timb/DBI/DBI.pm#Threads_and_Thread_Safety As far determining which modules are or are not threadsafe, read the perldocs! Thanks, Charles Alderman - Original Message - From: Perl Rob [EMAIL PROTECTED] Sent: Thu, 19 Jun 2008 08:52:30 -0600 Re: Re: [perl-win32-gui-users] Avoid the appearance of a frozen Thanks for all the great responses! I changed my code so that each GUI handle is managed only by the thread that created it. This works perfect--and has eliminated all the crasing I was seeing! As a follow-up question, how do you know *for sure* which modules are not thread-safe? For example, I wouldn't have guessed that DBI isn't thread safe. Thanks again, Rob - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Avoid the appearance of a frozen window
I've had some luck doing this using fork() and a pipe to communicate between the (pseudo) processes. On Win32, fork is emulated using perl threads. So it's basically the same thing. I haven't tested this on Perl 5.10 yet, but I've had a gui application built this way running and in use for more than 18 months now. Create and layout the window before spawning a new process/thread, as both pseudo processes can use the same gui handles. After the thread/fork instantiate the non threadsafe modules. (Like opening a DBI connection). Thanks, Charles Alderman - Original Message - From: Jeremy White [EMAIL PROTECTED] Sent: Wed, 18 Jun 2008 14:58:46 + Re: Re: [perl-win32-gui-users] Avoid the appearance of a frozen window Hi, If you are doing the processing in a loop, you can call DoEvents which will unfreeze the window and process all events currently in the queue. This approach would only work if the call to DoEvents happens frequently enough while you are processing. The alternative approach is to use threads. As long as you are using a modern perl (ie, 5.8.7+) and the latest version of Win32::GUI you should have no problems with threads. Cheers, jez. From: [EMAIL PROTECTED] To: perl-win32-gui-users@lists.sourceforge.net Date: Tue, 17 Jun 2008 21:38:50 -0600 Subject: [perl-win32-gui-users] Avoid the appearance of a frozen window Hi all, I’m curious: how do you prevent your window from looking like it’s frozen during lengthy operations? For example, suppose a user clicks a button that will trigger a very long event, such as copying a 10 GB file. While the really long event is underway, how do you free up your window so that it doesn’t appear unresponsive? I usually resort to writing two separate programs--the GUI and a “worker”--and I just launch the worker when needed. I realize threads are an option, but in my experience they are not always reliable (many Win32::GUI modules don’t seem to be thread-safe). Thanks, Rob _ http://clk.atdmt.com/UKM/go/msnnkmgl001007ukm/direct/01/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Avoid the appearance of a frozen window
On Wed, 18 Jun 2008, Charles Alderman wrote: I've had some luck doing this using fork() and a pipe to communicate between the (pseudo) processes. On Win32, fork is emulated using perl threads. So it's basically the same thing. I haven't tested this on Perl 5.10 yet, but I've had a gui application built this way running and in use for more than 18 months now. Create and layout the window before spawning a new process/thread, as both pseudo processes can use the same gui handles. You are not really supposed to use GUI handles from a thread that doesn't own them (the one that has created them). While read access is generally safe, modifying GUI objects from non-owning threads isn't. For example: http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx Cheers, -Jan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Avoid the appearance of a frozen window
- Original Message - From: Jan Dubois [EMAIL PROTECTED] Sent: Wed, 18 Jun 2008 10:58:28 -0700 Re: RE: [perl-win32-gui-users] Avoid the appearance of a frozen window You are not really supposed to use GUI handles from a thread that doesn't own them (the one that has created them). While read access is generally safe, modifying GUI objects from non-owning threads isn't. For example: http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx Cheers, -Jan Sure, race conditions and IPC are always issues to consider in multi-threaded applications. But, I don't think there is anything inherently flawed with pre-spawning off threads as event handlers for the various gui elements on a window. Just build the app to not make changes to the window in those threads. In fact, I feel like that's a preferred approach to spawning off a new thread after the main thread handles window events. Pre spawning/forking/whatever shifts a lot of overhead to the application initial load time, which leads to a better user experience. Users hate waiting after clicking. All of this kind of feels like a hack to me (I know all of these problems have been solved a bajillion times before), but I don't consider myself a great GUI programmer. I picked Win32::GUI because it gave me an easy on-ramp to building a professional looking windows gui application. And this was the quickest, best way for me to get my code out the door... :) Thanks, Charles Alderman - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
Re: [perl-win32-gui-users] Avoid the appearance of a frozen window
On Wed, 18 Jun 2008, Charles Alderman wrote: I've had some luck doing this using fork() and a pipe to communicate between the (pseudo) processes. On Win32, fork is emulated using perl threads. So it's basically the same thing. I haven't tested this on Perl 5.10 yet, but I've had a gui application built this way running and in use for more than 18 months now. Create and layout the window before spawning a new process/thread, as both pseudo processes can use the same gui handles. You are not really supposed to use GUI handles from a thread that doesn't own them (the one that has created them). While read access is generally safe, modifying GUI objects from non-owning threads isn't. For example: http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx Just to add that you can also spawn multiple threads, each creating their own Win32::GUI windows (with their own message queues) allowing each thread to have each an instance of the application. It might sound clunky, but it does scale well on dual/quad cores. Cheers, jez. _ http://clk.atdmt.com/UKM/go/msnnkmgl001007ukm/direct/01/- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
