Re^5: Calling a C function using malloc() in a XS

Yes, it seems not to be a bug, just a unconditioned feature.

The memory does not drop down while the process is running and it's a very bad thing when used in a mod_perl environment. The interpreter is embedded into Apache server and the the former is permanently loaded in memory. So, after a first use of the do_simulation() functions, the process' memory grows up and remains at the highest limit. Sometimes this limit could be more than 1 GB

Ok, perl 5.6 manages the memory this way. But why the (external) code provided in the XS file and using malloc()/free() has the same behaviour? Is it linked to a malloc() function provided by Perl itself? If so, how can I use the malloc() provided by my system? ("#undef malloc" doesn't work)

Comment on Re^5: Calling a C function using malloc() in a XS

Replies are listed 'Best First'.
Re^6: Calling a C function using malloc() in a XS by ikegami (Patriarch) on Aug 09, 2010 at 13:59 UTC
You could use an external process to do that job. A simulation that requires that much memory would probably benefit from being separate from the web server for other reasons anyway.	[reply]