in reply to Re: threads: spawn early to avoid the crush.
in thread threads: spawn early to avoid the crush.

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

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.

Replies are listed 'Best First'.
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
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 );

    The general ideas are

    1. 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) } }
    2. 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