in reply to Perl5.8.4 , threads - Killing the "async" kid

It appears to me that, as things stand now, you are calling exit() on the main thread, which shuts down the entire application, but you didn’t signal the child threads, nor did you wait for them to complete.

As shown in “thread signaling,” in the Threads documentation, you need to signal each thread to complete.   Then, use join() to cause the main thread to wait-for and reap each one.   Or, also as shown there, follow the KILL with an immediate detach(), although this seems less-than-elegant to me.   I would run one loop that signals each thread (first...), then a second loop that reaps each thread.

Putting a tiny sleep() call just before the main-thread ends never hurts, either.   An unnoticeable, but intentional, delay covers over a multitude of sins.   (You know, the irritating little timing-holes that never show up in testing, but always appear when the CEO is looking at a big demo.   I don’t like finger-dancing in such situations.)

Replies are listed 'Best First'.
Re^2: Perl5.8.4 , threads - Killing the "async" kid
by BrowserUk (Patriarch) on Oct 11, 2010 at 18:17 UTC
    As shown in “thread signaling,” in the Threads documentation, you need to signal each thread to complete.

    Could you post some working code to demonstrate that please?

Re^2: Perl5.8.4 , threads - Killing the "async" kid
by MonkeyMonk (Sexton) on Oct 11, 2010 at 16:39 UTC
    Hi Perl 5.8.4 does not have features where you can send a kill signal from the main thread. http://search.cpan.org/~nwclark/perl-5.8.4/pod/perlthrtut.pod

      Urgh...

      Well, then, as others have said:   you might just have to endure some messages.   They don’t do any harm.

      you can upgrade threads independent of perl
        you can upgrade threads independent of perl

        At what point did threads become a dual-life module? And can you safely upgrade a pre-dual-life version of Perl with a later CPAN version?