ithreads not behaving as expected

madorb has asked for the wisdom of the Perl Monks concerning the following question:

I've got a perl script, and i'm attempting to spawn a new thread. The (greatly simplified) flow is as such:

main_file.pl
-------------------
use strict;
use Env;
use Getopt::Long;
use Config::Properties;
use Net::FTP::Recursive;
use Net::SFTP::Foreign;
use File::Copy;
use File::Basename;
use Cwd;
use Fcntl ':mode';
use MIME::Base64::Perl;
use Net::MySQL;

...
  if(something){
    require("sub_file.pl");
    sub_from_sub_file();
  }
...


sub_file.pl
-------------------
use strict;
use XML::LibXML;
use Config::Properties;
use DBI;
use threads;

...
sub_from_sub_file(){
   print "Before\n";
   my $thr = threads->new(\&sub1);
   print "After\n";
}

sub sub1{
    print "HI!\n";
}
...
[download]

output would be: "Before"
Now, if i create a thread directly in the main, it seems to work okay, but calling it in the require()'d file it either 1) waits a moment then fails with "Alarm Clock" 2) or if i add $SIG{ALRM}="IGNORE"; it just waits forever.

For some reason the thread is never being spawned properly, i know this isn't my real code, which i can't really post, but does this issue make sense to anyone? I included all of the modules i'm using in the two scripts, but I'm not sure if that makes a big diff.

Comment on ithreads not behaving as expected Download Code

Replies are listed 'Best First'.
Re: ithreads not behaving as expected by BrowserUk (Patriarch) on Jul 16, 2009 at 21:50 UTC
This: `my $thr = threads->new(\sub1);` should be `my $thr = threads->new(\`&`sub1);` If you had warnings enabled, you'd've got: `Thread 1 terminated abnormally: Not a CODE reference at ...` Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP PCW	[reply] [d/l] [select]
Re^2: ithreads not behaving as expected by BrowserUk (Patriarch) on Jul 16, 2009 at 23:38 UTC
Then you will have to supply more information because what you've shown so far works as expected: `#! perl -sw use 5.010; use strict; our $FLAG; if( $FLAG ) { require '780835-s.pl'; doit(); }` [download] `#! perl -sw use 5.010; use strict; use threads; sub t{ say 'Hi from thread'; } sub doit { say 'Before'; my $t = threads->create( \&t ); say 'After'; } 1;` [download] `C:\test>780835-m -FLAG=0 C:\test>780835-m -FLAG=1 Before After Hi from thread Perl exited with active threads: 1 running and unjoined 0 finished and unjoined 0 running and detached` [download] Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP PCW	[reply] [d/l] [select]
Re^2: ithreads not behaving as expected by madorb (Novice) on Jul 16, 2009 at 22:16 UTC
sorry, that was a typo, it was correct in the real script. i'll update the above code.	[reply]
Re: ithreads not behaving as expected by SuicideJunkie (Vicar) on Jul 16, 2009 at 20:43 UTC
Do not worry about it not being your "real" code, as long as the issue still occurs. Replicating the issue in a separate environment and distilling the code down to the minimum required to show the issue is an excellent way to debug. Bugs often become obvious once you have shoveled most of the dirt out of the way. Unfortunately I don't know too much about ithreads, so one of the more veteran monks will have to step in to help with the details. One thing I do know is that the error message will be `"thread failed to start: blah blah blah"`, but what it probably means is "thread failed to end cleanly. The thread could have been running for quite some time before it dies and prints such a message.	[reply] [d/l]
Re: ithreads not behaving as expected by Corion (Patriarch) on Jul 16, 2009 at 21:35 UTC
If you're trying to mix threads and signals, my only advice is to avoid that. Threads and signals are two very OS-specificy concepts and they certaily don't mix well.	[reply]