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)
In reply to Re^5: Calling a C function using malloc() in a XS
by Anonymous Monk
in thread Calling a C function using malloc() in a XS
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |