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

Hi all,

I'm writing a perl Win32::GUI program.This program using multithreads, multithreads running is fine.i'm using Thread::Pool::Simple module for the multithreads.And using thread::shared for data sharing.Share is required for subroutines, so far everything is fine.Program when to use 2th subroutine for the print the array to screen, GUI crashes so GUI not wait the thread or not print array element;

System: Perl version (v5.12.4) built for MSWin32-x86-.. Binary build 1205 294981

Windows 7

use Win32::GUI; use threads; use threads::shared; my @SHARED; share(@SHARED); (...) &GET(@otherdata); #example (...) #1th subroutine sub GET { @data = @_; (...) sub workder { $data_2 = shift; (...) (...) for(...){ push(@SHARED, $_); } (...) } my $pool2 = Thread::Pool::Simple->new( min => 3, max => 20, do => [\&workder] ); foreach $getdatas (@data) { (...) } $pool2->join(); (...) &GET_2(); } #2th subroutine sub GET_2 { print $_,"\n" for @SHARED; #@SHARED not printing to screen }
Thank you, Regards.

Replies are listed 'Best First'.
Re: thread::share problem
by BrowserUk (Patriarch) on May 12, 2012 at 12:50 UTC

    You would be far more likely to get a solution if you posted runnable code that demonstrates the problem.


    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.

    The start of some sanity?

      Ok no problem of the code. I understand that I must use the lock() function.But what is this;

      Scalars leaked: 18 < this is no problem

      Scalars leaked: 18

      Scalars leaked: 18

      panic: COND_DESTROY (6). what is this?

      There are too many bugs in perl.

        panic: COND_DESTROY (6). what is this?

        It means that when perl came to destroy a condition var, when it attempted to close the handle to the associated semaphore, the handle was invalid.

        The usual cause of this is an attempt to destroy the condition var a second time.

        And the usual cause of that is programmer error.


        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.

        The start of some sanity?