but I've found it difficult to do in the past without Threads::Shared which has some serious limitations.

Hm. Seems simple enough to me?:

#! perl -slw
use strict;
use threads;
use threads::shared;

my $sem :shared;
sub tprint {
    lock $sem;
    print @_;
}

my $dieNow :shared = 0;
$SIG{INT} = sub {
    tprint 'sigint seen';
    $dieNow = 1;
    return;
};

sub thread {
    my $tid = threads->tid;
    my $delay = int rand 10;
    my $next = time + $delay;
    while( sleep 1 ) {
        last if $dieNow;
        redo unless time > $next;
        tprint "[$tid] ping";
        $next = time + $delay;
    }
    tprint "$tid] ending";
}

my @threads = map async( \&thread ), 1 .. 10;

sleep 1 until $dieNow;
$dieNow = 1;

$_->join for @threads;
[download]

Outputs:

C:\test>1007974
[3] ping
[9] ping
[1] ping
[3] ping
[2] ping
[4] ping
[3] ping
[1] ping
[9] ping
[5] ping
[3] ping
[6] ping
[10] ping
sigint seen
[3] ping
7] ending
2] ending
5] ending
8] ending
1] ending
9] ending
4] ending
6] ending
10] ending
3] ending
[download]

browserUk++

I keenly (and painfully) remember getting segfault after segfault with threads::shared on distributed cluster of rhel 5 servers I had to work with about 6 months back. I eventually gave up and just used stock threads. The application was about 2K lines and I wasn't about to try to find out why threads::shared wouldn't work...everything looked fine, and I was following all the rules. What's more, I needed to share some very complex datastructures (I believe the real problem was exactly that, and it was an uncompromising requirement). I got around the segfaults by using a not-so-elegant fix (Storable::lock_store / Storable::lock_retrieve on a ramdisk). I'm not proud of that, but it worked and it's been running in production as a persistent service for worldwide venues going on several months now -- no memleaks, no segfaults, no problems. It had to be done to get it to work on the old rhel 5 platforms.

I chocked it up to having a perl that was too old when the same code ran fine on my own servers which had the most recent stable perl. I made a mental note that in the future I would need to be more careful with threads::shared (or avoid it entirely) when writing code that might need to run on legacy servers.

Just my own personal experience; YMMV

I appreciate the time you took in coding that example for me. I don't take it lightly that you freely gave your own valuable time to do that. Thank you.

--
Tommy
$ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'

I keenly (and painfully) remember getting segfault after segfault with threads::shared on distributed cluster of rhel 5 servers I had to work with about 6 months back. I eventually gave up and just used stock threads. The application was about 2K lines and I wasn't about to try to find out why threads::shared wouldn't work...everything looked fine, and I was following all the rules.

Could you show me the faulting code; here or privately?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

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 Neil Armstrong

Now that I think about it again...I could have used packed strings, or some other similar marshalling method and just shared a re-vivifiable-as-hashref scalar string. *Sigh*

--
Tommy
$ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'