in reply to General memory management for embedded/extended perl with C threads

The offical interface to malloc() from XS is New, Newz, Renew, Safefree. See the section "Memory Management" in perlapi.pod

As an aside, note that you have to be very careful when creating multiple threads inside perl. Most of perl's data structures are private to each interpreter and are not designed to be shared by multiple threads. So for example if you have two threads accessing the same SV structure, madness will ensue. Make sure that only the original thread that called the XS code allocates/releases any further Perl data. If the other threads only do private stuff unrelated to perl then that's okay.

Dave.

  • Comment on Re: General memory management for embedded/extended perl with C threads

Replies are listed 'Best First'.
Re^2: General memory management for embedded/extended perl with C threads
by Anonymous Monk on Nov 15, 2004 at 15:36 UTC
    Ok - I know what the problem is - I just don't know a proper solution:)

    Just creating and initialising a Perl interpreter when the C thread starts solves all the problems, even though this C thread has no interaction with Perl at all . It seems when malloc and co are redefined, they use pointers that are associated with the current thread. In other words, when you use the Perl header files (XSUB.h and I suspect some of the others) there HAS to be an Perl interpreter initialised on all threads if you use malloc and it's friends.

    Ideally, I don't want a Perl interpreter in each C thread:) There must be some way to build this module to use a global wide malloc?