Re: threads: spawn early to avoid the crush.

I've been doing that way in all my thread examples. :-) What I do is first setup the shared variables, then IMMEDIATELY creating the threads and put them in a sleep loop, waiting for a signal(thru shared vars) to wake up and start running. I usually use a 1 second loop in the threads, which may seem sluggish, but you could reduce it to milliseconds if desired.

Even in the latest Gtk2 code, which allows some fancier thread work, thru their thread-safety mechanism, experts like muppet still say the best way is to do it like you suggest. Create the threads first, before anything else is declared, and you will have few problems.

This is the basic thread I use, you can either hard code the threads code, or pass it via shared-variable and eval it. When the thread is created, it goes right to sleep, and wakes up once per second to see if it needs to awake. The one drawback with this method, is you need to clean them up when exiting......wake them up, and tell them to die, then join them.

sub work{
  my $dthread = shift;
    $|++;
    while(1){
       if($shash{$dthread}{'die'} == 1){ goto END };

       if ( $shash{$dthread}{'go'} == 1 ){

    eval( system( $shash{$dthread}{'data'} )    );

   foreach my $num (1..100){
          $shash{$dthread}{'progress'} = $num;
       print "\t" x $dthread,"$dthread->$num\n";
       select(undef,undef,undef, .5);
       if($shash{$dthread}{'go'} == 0){last}
       if($shash{$dthread}{'die'} == 1){ goto END };
       }

    $shash{$dthread}{'go'} = 0; #turn off self before returning       
       }else
         { sleep 1 }
    }
END:
}
[download]

I'm not really a human, but I play one on earth. flash japh

Comment on Re: threads: spawn early to avoid the crush. Download Code

Replies are listed 'Best First'.
Re^2: threads: spawn early to avoid the crush. by BrowserUk (Patriarch) on Mar 02, 2006 at 17:32 UTC
Yes. I've been using and describing these techniques here for a 3 years or more, but I am looking for a way to ecapsulate the messy and fiddly business of shared data, access control and the process of spawning 'clean&light' threads into a module with simple interface. I gotten close a couple of times, but there is always something that I haven't found a good way to do Your example code misses the point. In a nutshell, the problem is how to pass a coderef + parameters + context to a pre-existing dormant thread. And how to return the thread handle from that thread to the calling code for joining and results retrieval. Possible interface: `use threads::lite; my @threads = threads::lite->spawn( 10 ); ... ## Then when I know what I want a thread to do my $Xthread = pop threads; $Xthread->run( \&doX, @Xargs ); .... my @Xresults = $Xthread->join;` [download] Or: How to start a thread factory thread early so that you have a clean thread and then later pass a coderef + parameters + context to that factory thread; have it spawn a new (clean) thread; and then return the handle from the new thread to the caller for subsequent joining and results retrieval. Possible interface: `use threads::lite; my $threadFactory = threads::lite->genFactory; .... my( $Xthread ) = $threadsFactory->create( \&doX, @Xargs ); my( $Ythread ) = $threadsFactory->create( \&doY, @Yargs );` [download] Don't take any notice of the module/method names shown. I could care less whether they are `camelCase()` or `hugely_verbose_with_under_scores()`--though I have my preferences like others, and I'd prefer that they weren't `Hugely_Verbose_With_Camel_Case_And_Underscores()` as I've encountered occasionally. The crux of the matter is how to create light threads (which means early), but use them when I need them; and without having to reinvent the wheel of queues and synchronisation and all that good stuff in every program; and without cloning everything in my current thread into every thread I spawn. Ie. A simple interface to lightweight, 'only-clone-what-is-needed' threads. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]
Re^3: threads: spawn early to avoid the crush. by zentara (Cardinal) on Mar 02, 2006 at 20:15 UTC
Isn't it amazing how far we've come so far? I'm sure you've examined the latest threads-related nodes where it is discussed that the new separate threads:shared module now has the ability to bless shared refs. I'm thinking that object could be the basis of the thread object. You create a shared hash, then bless it into an object, then use that object as the basis of the thread object. Add to the blessed object the sleeping worker thread(automatically), which shares that shared hash ref, then make up the methods, etc, to pass code to be evaled, go to sleep, wake up, die, join, etc. I'm not much into making objects, but that would be my first attempt. You know more about it than me, I'm pretty content to stick with functional worker threads which I control thru a hash. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^3: threads: spawn early to avoid the crush. by radiantmatrix (Parson) on Mar 03, 2006 at 16:17 UTC
I like this idea. A suggestion for the interface: `use threads::lite; my $factory = threads::line->new( -threads => 10 ); #reserve 10 thread +s my $x_thr = $factory->create( \&doX, \@Xargs, \%optional_configs ); my $y_thr = $factory->create( \&doY, \@Yargs );` [download] The general ideas are Spawn a number of threads up-front, if you use more, they are spawned as needed. When the factory is created, the threads could run something like: `sub _default_thread { my $thr_id = shift; if (defined $s_coderef[$thr_id] && ref $s_coderef[$thr_id] eq 'CODE +') { $s_coderef[$thr_id]->(@{ $s_param[$thr_id] }); $s_coderef[$thr_id] = undef; } else { sleep(1) } }` [download] Pass arguments as single ARRAYref, opening the door for per-thread configuration. This is just off the top of my head, so take it as such. <-radiant.matrix-> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code I haven't found a problem yet that can't be solved by a well-placed trebuchet	[reply] [d/l] [select]