in reply to [Win32] pthreads and memory allocation

at which point it crashes. (Irrespective of how many threads I specify it always crashes when *all* threads have reached the stage of having to allocate the memory.)

Probably none of the started threads will get any time slice until your main thread enters the join wait state. Try adding a 1 second sleep inside the loop and it will probably crash as soom as the first one tries to run.

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.
  • Comment on Re: [Win32] pthreads and memory allocation

Replies are listed 'Best First'.
Re^2: [Win32] pthreads and memory allocation
by syphilis (Archbishop) on Nov 22, 2011 at 07:07 UTC
    Yes, it then crashes as soon as the 1st thread tries to malloc. Then, having cleared the popup, I get some more output indicating that the 2nd thread got as far as the malloc, too. But it never gets any further than that.

    Cheers,
    Rob
[reply]

      I think that the problem is likely that malloc has been redefined by the Perl/XS headers and the Perl code that gets called is trying to access the perl thread context for the "current" thread. Which of course doesn't exist because the thread was not created by Perl.

      See Re: Win32::Internet crash, XS, callbacks, perl stack & context, windows api, interpreter thread safety, 1 perl, many C threads by windows for previous related discussion on the problem.

      See also Perl crash during perl_clone for a long and twisty thread where I worked through the same problem to a successful conclusion.

      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.
[reply]

      Another thought. If you add #undef malloc just prior to your use of malloc, you may find that the code will run without immediately crashing. But I make no claim that you won't run into similar problems later on.

      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.
[reply]
[d/l]
        add #undef malloc just prior to your use of malloc

        Ooow .... I like *that* idea :-)
        I've actually placed the '#undef malloc' at the very start of the C code in that script, and the script now runs fine.

        Beyond that, nothing has yet been established. Now it's just a matter of seeing whether the same approach can help with PDL (which is where the actual problem that prompted this thread lies.)

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom