From: Brian M. <bmi...@di...> - 2005-12-29 05:06:28
|
I'm surprised that this works at all, even as a script. I'd expect the animation to hang, because the script is stopped waiting for your gpresult program to run. You may want to consider running gpresult in a separate thread Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di... -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Igor Anufriyenko Sent: Wednesday, December 28, 2005 10:34 PM To: per...@li... Subject: [perl-win32-gui-users] PerlApp issue Hello, After compiling Win32::GUI script with PerlApp PDK 6.0.2 and running it as EXE Animation control freezes while fork() or system() are executed on the background to run CPU-intensive processes. However, uncompiled .PL script runs fine - AVI file is being played OK. Does anybody have a workaround ? or had a similar issue? code looks similar to this: sub btn_Start_Click { $animation->Open(file.avi); $animation->Play(0,-1,-1); $animation->Show(); &runsomething(); } sub runsomething { open CH, "gpresult |"; while (<CH>) { #do something...; } # or : system("gpresult"); close CH; } As mentioned above, perl script.pl runs just fine, though child process utilizes up to 99% of CPU time. I have tried DoEvents() with no effect whatsoever. Thank you, Igor. --- avast! Antivirus: Inbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/28/2005 10:41:46 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/29/2005 12:05:58 AM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com |
From: Igor A. <ig...@am...> - 2005-12-30 01:32:21
|
Brian, I have tried fork(), threads, Thread - none of them work. So far opening a pipe for reading open (CM,"gpresult |" ) and system() = function proved to work in uncompiled script. The latter is quite = interesting since it does a hidden fork() for you. All what I am trying to achieve is running findfile animation to spice = up users' passtime while shell utilities running on the background. Modules used in this script are Win32::OLE, Win32::GUI::Loft, Win32(); A working example of the multi-thread implementation in the GUI script = would be much appreciated. Thank you, ----- Original Message -----=20 From: Brian Millham=20 To: 'Igor Anufriyenko'=20 Sent: Wednesday, December 28, 2005 11:58 PM Subject: RE: [perl-win32-gui-users] PerlApp issue I'm surprised that this works at all, even as a script. I'd expect = the animation to hang, because the script is stopped waiting for your = gpresult program to run. You may want to consider running gpresult in a separate thread. Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di...=20 -----Original Message----- From: per...@li... = [mailto:per...@li...] On Behalf Of = Igor Anufriyenko Sent: Wednesday, December 28, 2005 10:34 PM To: per...@li... Subject: [perl-win32-gui-users] PerlApp issue Hello, After compiling Win32::GUI script with PerlApp PDK 6.0.2 and running = it as EXE Animation control freezes while fork() or system() are = executed on the background to run CPU-intensive processes. However, uncompiled .PL script runs fine - AVI file is being played = OK. Does anybody have a workaround ? or had a similar issue? code looks similar to this: sub btn_Start_Click { $animation->Open(file.avi); $animation->Play(0,-1,-1); $animation->Show(); &runsomething(); } sub runsomething { open CH, "gpresult |"; while (<CH>) { #do something...; } # or : system("gpresult"); close CH; } As mentioned above, perl script.pl runs just fine, though child = process utilizes up to 99% of CPU time. I have tried DoEvents() with no effect whatsoever. Thank you, Igor. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/28/2005 11:58:16 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com |
From: Brian M. <bmi...@di...> - 2005-12-30 01:49:43
|
If you can give me a code sample, I can try it on my system (W2K) and compile it with Perl2Exe. Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di... -----Original Message----- From: Igor Anufriyenko [mailto:ig...@am...] Sent: Thursday, December 29, 2005 8:10 PM To: Brian Millham Subject: Re: [perl-win32-gui-users] PerlApp issue Brian, Amazingly, it runs. I have tried fork, threads, Thread, system inside of fork - all for nothing. Plain old system() works the best, which btw does fork() on the background. My problem is that PerlApp looses something in translation and it stops working. Igor. ----- Original Message ----- From: Brian Millham <mailto:bmi...@di...> To: 'Igor <mailto:ig...@am...> Anufriyenko' Sent: Wednesday, December 28, 2005 11:58 PM Subject: RE: [perl-win32-gui-users] PerlApp issue I'm surprised that this works at all, even as a script. I'd expect the animation to hang, because the script is stopped waiting for your gpresult program to run. You may want to consider running gpresult in a separate thread. Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di... -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Igor Anufriyenko Sent: Wednesday, December 28, 2005 10:34 PM To: per...@li... Subject: [perl-win32-gui-users] PerlApp issue Hello, After compiling Win32::GUI script with PerlApp PDK 6.0.2 and running it as EXE Animation control freezes while fork() or system() are executed on the background to run CPU-intensive processes. However, uncompiled .PL script runs fine - AVI file is being played OK. Does anybody have a workaround ? or had a similar issue? code looks similar to this: sub btn_Start_Click { $animation->Open(file.avi); $animation->Play(0,-1,-1); $animation->Show(); &runsomething(); } sub runsomething { open CH, "gpresult |"; while (<CH>) { #do something...; } # or : system("gpresult"); close CH; } As mentioned above, perl script.pl runs just fine, though child process utilizes up to 99% of CPU time. I have tried DoEvents() with no effect whatsoever. Thank you, Igor. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/28/2005 11:58:16 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Inbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:20:42 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:40:53 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com |
From: Brian M. <bmi...@di...> - 2005-12-30 01:49:51
|
I haven't played with threads while using Win32::GUI. I have created a fairly complicated perl based service that used threads, so I'd be willing to help you out with this one. Supply me with a sample script (with animation files attached) and I'll see if I can get a threaded version running. For the Win32::GUI guirus (spelling intended:-)), is Win32::GUI thread safe? Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di... -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Igor Anufriyenko Sent: Thursday, December 29, 2005 8:31 PM To: per...@li... Subject: Re: [perl-win32-gui-users] PerlApp issue Brian, I have tried fork(), threads, Thread - none of them work. So far opening a pipe for reading open (CM,"gpresult |" ) and system() function proved to work in uncompiled script. The latter is quite interesting since it does a hidden fork() for you. All what I am trying to achieve is running findfile animation to spice up users' passtime while shell utilities running on the background. Modules used in this script are Win32::OLE, Win32::GUI::Loft, Win32(); A working example of the multi-thread implementation in the GUI script would be much appreciated. Thank you, ----- Original Message ----- From: Brian Millham <mailto:bmi...@di...> To: 'Igor <mailto:ig...@am...> Anufriyenko' Sent: Wednesday, December 28, 2005 11:58 PM Subject: RE: [perl-win32-gui-users] PerlApp issue I'm surprised that this works at all, even as a script. I'd expect the animation to hang, because the script is stopped waiting for your gpresult program to run. You may want to consider running gpresult in a separate thread. Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di... -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Igor Anufriyenko Sent: Wednesday, December 28, 2005 10:34 PM To: per...@li... Subject: [perl-win32-gui-users] PerlApp issue Hello, After compiling Win32::GUI script with PerlApp PDK 6.0.2 and running it as EXE Animation control freezes while fork() or system() are executed on the background to run CPU-intensive processes. However, uncompiled .PL script runs fine - AVI file is being played OK. Does anybody have a workaround ? or had a similar issue? code looks similar to this: sub btn_Start_Click { $animation->Open(file.avi); $animation->Play(0,-1,-1); $animation->Show(); &runsomething(); } sub runsomething { open CH, "gpresult |"; while (<CH>) { #do something...; } # or : system("gpresult"); close CH; } As mentioned above, perl script.pl runs just fine, though child process utilizes up to 99% of CPU time. I have tried DoEvents() with no effect whatsoever. Thank you, Igor. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/28/2005 11:58:16 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Inbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:41:02 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:46:27 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com |
From: Igor A. <ig...@am...> - 2005-12-30 02:21:46
|
Brian, Thanks for the offer. Will send as soon as I get to my Production box. Meanwhile, I have found message from Johan Lindstrom with = multi-threaded version of his FetchURL demo. Blair Sutton posted info = about working M-T model which uses Thread::Queue module to make a queue = sub before Dialog phase of the script. Queue accepts @ARGS from the = Event handlers later. Anyhow, I will send you a my code tomorrow. Thanks. Igor.=20 ----- Original Message -----=20 From: Brian Millham=20 To: 'Igor Anufriyenko' ; per...@li...=20 Sent: Thursday, December 29, 2005 8:46 PM Subject: RE: [perl-win32-gui-users] PerlApp issue I haven't played with threads while using Win32::GUI. I have created = a fairly complicated perl based service that used threads, so I'd be = willing to help you out with this one. Supply me with a sample script (with animation files attached) and = I'll see if I can get a threaded version running. For the Win32::GUI guirus (spelling intendedJ), is Win32::GUI thread = safe? Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di...=20 -----Original Message----- From: per...@li... = [mailto:per...@li...] On Behalf Of = Igor Anufriyenko Sent: Thursday, December 29, 2005 8:31 PM To: per...@li... Subject: Re: [perl-win32-gui-users] PerlApp issue Brian, I have tried fork(), threads, Thread - none of them work. So far opening a pipe for reading open (CM,"gpresult |" ) and system() = function proved to work in uncompiled script. The latter is quite = interesting since it does a hidden fork() for you. All what I am trying to achieve is running findfile animation to = spice up users' passtime while shell utilities running on the = background. Modules used in this script are Win32::OLE, Win32::GUI::Loft, Win32(); A working example of the multi-thread implementation in the GUI script = would be much appreciated. Thank you, ----- Original Message -----=20 From: Brian Millham=20 To: 'Igor Anufriyenko'=20 Sent: Wednesday, December 28, 2005 11:58 PM Subject: RE: [perl-win32-gui-users] PerlApp issue I'm surprised that this works at all, even as a script. I'd expect = the animation to hang, because the script is stopped waiting for your = gpresult program to run. You may want to consider running gpresult in a separate thread. Brian Millham This message traveled at least 44,000 miles to reach you! Creator of the DW6000 Monitor http://www.millham.net/dw6000 bmi...@di...=20 -----Original Message----- From: per...@li... = [mailto:per...@li...] On Behalf Of = Igor Anufriyenko Sent: Wednesday, December 28, 2005 10:34 PM To: per...@li... Subject: [perl-win32-gui-users] PerlApp issue Hello, After compiling Win32::GUI script with PerlApp PDK 6.0.2 and running = it as EXE Animation control freezes while fork() or system() are = executed on the background to run CPU-intensive processes. However, uncompiled .PL script runs fine - AVI file is being played = OK. Does anybody have a workaround ? or had a similar issue? code looks similar to this: sub btn_Start_Click { $animation->Open(file.avi); $animation->Play(0,-1,-1); $animation->Show(); &runsomething(); } sub runsomething { open CH, "gpresult |"; while (<CH>) { #do something...; } # or : system("gpresult"); close CH; } As mentioned above, perl script.pl runs just fine, though child = process utilizes up to 99% of CPU time. I have tried DoEvents() with no effect whatsoever. Thank you, Igor. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-1, 12/28/2005 Tested on: 12/28/2005 11:58:16 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Inbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:41:02 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0552-2, 12/29/2005 Tested on: 12/29/2005 8:46:27 PM avast! is copyright (c) 2000-2003 ALWIL Software. http://www.avast.com |
From: Jeremy W. <jez...@ho...> - 2005-12-30 11:15:36
|
>For the Win32::GUI guirus (spelling intended:-)), is Win32::GUI thread >safe? I'm not a guru, but if you want a rough answer: Yes, Win32::GUI is thread safe. Well, sort off:) Rob May and I have had an exchange of emails about how to make Win32::GUI thread programming easier, after some testing we came up with some interesting results. The first thing to mention is that the main limiting factor is perl itself. Only the 5.8.x codeline is worth considering, with the latest version (5.8.7) being the best to use. The core of Win32::GUI is indeed thread safe - all the XS/C code - (well, we have yet to find an issue). Rob found that a couple of lines of perl code is needed within Win32-GUI to make itself fully thread safe. This can be achieved with the following code: use strict; use warnings; use 5.007002; # Perl 5.7.2 or higher needed for CLONE_SKIP use threads; use threads::shared; use Win32::GUI(); # make Win32::GUI threadsafe sub Win32::GUI::CLONE_SKIP {1}; sub Win32::GUI::Timer::CLONE_SKIP {1}; The CLONE_SKIP function would need to be added for all Win32-GUI objects that you would use. New versions of Win32-GUI would have these functions already added. Win32-GUI is surprising robust with threading, as each spawned thread can create it's own windows, with the creating thread responding to events for that window. The major limitation is that you can't change the thread that handles the event for a window. For example, if thread A creates a window, you can't make thread B respond to events for that window. With this limitation in mind, you can do things like: #!perl -w $|=1; use strict; use warnings; use 5.007_002; # Perl 5.7.2 or higher needed for CLONE_SKIP use threads; use Win32::GUI(); # Make Win32::GUI thread-safe sub Win32::GUI::CLONE_SKIP {1}; my $count=1; my $numberOfWorkers=5; my $main=MainWindow('main',$count++); my $thr; for (1..$numberOfWorkers) { $thr = threads->create(\&Worker2,"worker $_",$count++); $thr->detach(); } $main->Show(); Win32::GUI::Dialog(); sub MainWindow { my ($name, $number)=@_; my $mw = Win32::GUI::Window->new( -title => "$name thread window", -pos => [400,400], -size => [300,200], ); $mw->AddTextfield ( -name => 'Log', -height => 80, -width => 160, -top => 4, -left => 4, -multiline => 1, -addstyle => 2097152, -addstyle=>4096, ); return $mw; } sub Worker2 { my ($name, $number)=@_; my $mw = Win32::GUI::Window->new( -title => "$name thread window", -pos => [100,100], -size => [300,200], ); $mw->AddButton( -text => 'Do some work in this window', -pos => [114, 10], -height => 20, -onClick => \&Job, ); $mw->AddTextfield ( -name => 'Process', -height => 20, -width => 35, -top => 2, -left => 20, ); $mw->Process->Text($number); $mw->Show(); #the thread enters the Dialog phase Win32::GUI::Dialog(); } sub Job { my $self=shift; my $parent=$self->GetParent(); my $id=threads->tid(); #do some work for 2 seconds Win32::Sleep(2000); my $item=$parent->Process->Text(); print "finished $item in thread $id"; } Which creates 6 windows, each one running in it's own thread. You'll need the latest version of Win32-GUI to run this example. Rob May has developed some very interesting code that will make the communication between threads that use Win32-GUI objects so easy to do, that we'll all be building threading win32-gui apps in our sleep:) Cheers, jez. |
From: Glenn W M. <gwm...@gm...> - 2005-12-30 14:10:16
|
Jez, For a "rough" answer, that was very useful and interesting! These little demo scripts are a goldmine of information. I have been using threads to carry out background work while updating a progress bar in the main window and providing a cancel button. It will be interesting to see Rob's inter-thread communication code when it's ready. One thing I noticed in my program, that also occurs when I run your example, is that I get a message complaining that "A thread exited while 6 threads were running" if the main window is exited first. I thought the detach() method was supposed to prevent that. I seem to remember that when you actually do a join(), as suggested in the documentation, there are other problems. Do you also see this? Do you know what is going wrong? Glenn -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Jeremy White Sent: Friday, 30 December, 2005 08:16 To: bmi...@di...; ig...@am...; per...@li... Subject: RE: [perl-win32-gui-users] PerlApp issue >For the Win32::GUI guirus (spelling intended:-)), is Win32::GUI thread >safe? I'm not a guru, but if you want a rough answer: Yes, Win32::GUI is thread safe. Well, sort off:) Rob May and I have had an exchange of emails about how to make Win32::GUI thread programming easier, after some testing we came up with some interesting results. The first thing to mention is that the main limiting factor is perl itself. Only the 5.8.x codeline is worth considering, with the latest version (5.8.7) being the best to use. The core of Win32::GUI is indeed thread safe - all the XS/C code - (well, we have yet to find an issue). Rob found that a couple of lines of perl code is needed within Win32-GUI to make itself fully thread safe. This can be achieved with the following code: use strict; use warnings; use 5.007002; # Perl 5.7.2 or higher needed for CLONE_SKIP use threads; use threads::shared; use Win32::GUI(); # make Win32::GUI threadsafe sub Win32::GUI::CLONE_SKIP {1}; sub Win32::GUI::Timer::CLONE_SKIP {1}; The CLONE_SKIP function would need to be added for all Win32-GUI objects that you would use. New versions of Win32-GUI would have these functions already added. Win32-GUI is surprising robust with threading, as each spawned thread can create it's own windows, with the creating thread responding to events for that window. The major limitation is that you can't change the thread that handles the event for a window. For example, if thread A creates a window, you can't make thread B respond to events for that window. With this limitation in mind, you can do things like: #!perl -w $|=1; use strict; use warnings; use 5.007_002; # Perl 5.7.2 or higher needed for CLONE_SKIP use threads; use Win32::GUI(); # Make Win32::GUI thread-safe sub Win32::GUI::CLONE_SKIP {1}; my $count=1; my $numberOfWorkers=5; my $main=MainWindow('main',$count++); my $thr; for (1..$numberOfWorkers) { $thr = threads->create(\&Worker2,"worker $_",$count++); $thr->detach(); } $main->Show(); Win32::GUI::Dialog(); sub MainWindow { my ($name, $number)=@_; my $mw = Win32::GUI::Window->new( -title => "$name thread window", -pos => [400,400], -size => [300,200], ); $mw->AddTextfield ( -name => 'Log', -height => 80, -width => 160, -top => 4, -left => 4, -multiline => 1, -addstyle => 2097152, -addstyle=>4096, ); return $mw; } sub Worker2 { my ($name, $number)=@_; my $mw = Win32::GUI::Window->new( -title => "$name thread window", -pos => [100,100], -size => [300,200], ); $mw->AddButton( -text => 'Do some work in this window', -pos => [114, 10], -height => 20, -onClick => \&Job, ); $mw->AddTextfield ( -name => 'Process', -height => 20, -width => 35, -top => 2, -left => 20, ); $mw->Process->Text($number); $mw->Show(); #the thread enters the Dialog phase Win32::GUI::Dialog(); } sub Job { my $self=shift; my $parent=$self->GetParent(); my $id=threads->tid(); #do some work for 2 seconds Win32::Sleep(2000); my $item=$parent->Process->Text(); print "finished $item in thread $id"; } Which creates 6 windows, each one running in it's own thread. You'll need the latest version of Win32-GUI to run this example. Rob May has developed some very interesting code that will make the communication between threads that use Win32-GUI objects so easy to do, that we'll all be building threading win32-gui apps in our sleep:) Cheers, jez. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Perl-Win32-GUI-Users mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/ |
From: Jeremy W. <jez...@ho...> - 2005-12-30 15:02:04
|
>For a "rough" answer, that was very useful and interesting! These little >demo scripts are a goldmine of information. I have been using threads to >carry out background work while updating a progress bar in the main window >and providing a cancel button. It will be interesting to see Rob's >inter-thread communication code when it's ready. The situation you describe above is probably going to be the most common win32-gui thread situation, and I'm sure you've gone through a couple of strange workarounds to get this working:) Rob's code solves several big problems, including how to trigger an event in a thread that is in the windows message loop. Basically, Rob's solution uses a thread safe queue with one end attached to a window (thus, to the thread responding to the events). When an item is added to the queue from a different thread, the window thread responds by firing an event, where you receive the item that was added on the queue. My explanation is poor, but the end results is very simple, event driven, elegant and efficient solution. >One thing I noticed in my program, that also occurs when I run your >example, >is that I get a message complaining that "A thread exited while 6 threads >were running" if the main window is exited first. I thought the detach() >method was supposed to prevent that. I seem to remember that when you >actually do a join(), as suggested in the documentation, there are other >problems. Do you also see this? Do you know what is going wrong? Yes I get this too. I think that the message is mainly a warning, and in most simple cases can be ignored. The correct approach is for all child threads to terminate smoothly, under the control of the main thread before the main thread itself terminates. Cheers, jez. |
From: Emmanuel E <emm...@gm...> - 2005-12-30 15:50:03
|
Rob's work sounds cool! About the threads exiting issue this is what the manual page says: ------------- WARNINGS A thread exited while %d other threads were still running A thread (not necessarily the main thread) exited while there were still other threads running. Usually it's a good idea to first collect the return values of the created threads by joining them, and only then exit from the main thread. ------------- In my experience the detach method seems to be experimental. The main thread exiting before other threads causes the entire script to exit. Also a thread using the Crypt::SSLeay or Net::SSLeay module, causes weird crashes if detached, but works "reasonably" okay if not detached. Hopefully this will be fixed in a later version of Perl and/or SSL modules! Cheers, Emmanuel p.s. Wishing you all a great year ahead. ----- Original Message ----- From: "Jeremy White" <jez...@ho...> To: <gwm...@gm...>; <bmi...@di...>; <ig...@am...>; <per...@li...> Sent: Friday, December 30, 2005 8:31 PM Subject: RE: [perl-win32-gui-users] PerlApp issue >>One thing I noticed in my program, that also occurs when I run your >>example, >>is that I get a message complaining that "A thread exited while 6 threads >>were running" if the main window is exited first. I thought the detach() >>method was supposed to prevent that. I seem to remember that when you >>actually do a join(), as suggested in the documentation, there are other >>problems. Do you also see this? Do you know what is going wrong? > > Yes I get this too. I think that the message is mainly a warning, and in > most simple cases can be ignored. The correct approach is for all child > threads to terminate smoothly, under the control of the main thread before > the main thread itself terminates. > > Cheers, > > jez. |
From: Glenn W M. <gwm...@gm...> - 2005-12-30 16:58:33
|
Emmanuel, I think you're right: something isn't quite right about the detach method. In Jez's example, there doesn't seem to be any difference if you comment out the call to the method or not. A couple of other lines from the manual: "If the program exits without all other threads having been either joined or detached, then a warning will be issued." "If you don't want the return values and don't want to wait for the thread to finish, you should call the detach() method instead, as described next." So I'm pretty sure that we shouldn't see the error message when exiting the main thread after having called detach() but, to be fair, nothing worse than the error message seems to happen. I was afraid that the problem was in Win32::GUI, but you see the same behaviour in a non-GUI program. All the best, Glenn -----Original Message----- From: per...@li... [mailto:per...@li...] On Behalf Of Emmanuel E Sent: Friday, 30 December, 2005 12:51 To: per...@li... Subject: Re: [perl-win32-gui-users] PerlApp issue Rob's work sounds cool! About the threads exiting issue this is what the manual page says: ------------- WARNINGS A thread exited while %d other threads were still running A thread (not necessarily the main thread) exited while there were still other threads running. Usually it's a good idea to first collect the return values of the created threads by joining them, and only then exit from the main thread. ------------- In my experience the detach method seems to be experimental. The main thread exiting before other threads causes the entire script to exit. Also a thread using the Crypt::SSLeay or Net::SSLeay module, causes weird crashes if detached, but works "reasonably" okay if not detached. Hopefully this will be fixed in a later version of Perl and/or SSL modules! Cheers, Emmanuel p.s. Wishing you all a great year ahead. ----- Original Message ----- From: "Jeremy White" <jez...@ho...> To: <gwm...@gm...>; <bmi...@di...>; <ig...@am...>; <per...@li...> Sent: Friday, December 30, 2005 8:31 PM Subject: RE: [perl-win32-gui-users] PerlApp issue >>One thing I noticed in my program, that also occurs when I run your >>example, >>is that I get a message complaining that "A thread exited while 6 threads >>were running" if the main window is exited first. I thought the detach() >>method was supposed to prevent that. I seem to remember that when you >>actually do a join(), as suggested in the documentation, there are other >>problems. Do you also see this? Do you know what is going wrong? > > Yes I get this too. I think that the message is mainly a warning, and in > most simple cases can be ignored. The correct approach is for all child > threads to terminate smoothly, under the control of the main thread before > the main thread itself terminates. > > Cheers, > > jez. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Perl-Win32-GUI-Users mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/ |