Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation? Normally in an interactive session "some memory" might not be a problem, because it will be run shortly; but I prefer clean solutions. And also, if it's much mem, which is allocated each time, and one does many trials and Ctr-C's, even an interactive session might eat a lot of mem. So I would be interested in a solution to this (potential) problem. Ciao, Oliver
Ctrl-C of functions that allocated mem
6 messages · Simon Urbanek, oliver
On Jun 8, 2011, at 8:06 PM, oliver wrote:
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation?
Yes, if you read R-exts: http://r.research.att.com/man/R-exts.html#Memory-allocation you would know that you're not supposed to use malloc/calloc at all and if you allow interruption ("regular" C code does not) R_alloc does what you asked about. Cheers, Simon
Normally in an interactive session "some memory" might not be a problem, because it will be run shortly; but I prefer clean solutions. And also, if it's much mem, which is allocated each time, and one does many trials and Ctr-C's, even an interactive session might eat a lot of mem. So I would be interested in a solution to this (potential) problem. Ciao, Oliver
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
On Jun 8, 2011, at 8:06 PM, oliver wrote:
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation?
Yes, if you read R-exts: http://r.research.att.com/man/R-exts.html#Memory-allocation you would know that you're not supposed to use malloc/calloc at all and if you allow interruption ("regular" C code does not) R_alloc does what you asked about.
OK. There are some pages I didn't read so far. I'm just too unpatient.... ...maybe should go on reading ;) Thanks for the hint to the R-exts.html. .... I hope there I also will find a solution for my filename-problem: want a char* on a filename, must use const char* (strdup() would match that issue), and I should not use my own allocation mechanisms. Then there must be something to address this. Ciao, Oliver
On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
On Jun 8, 2011, at 8:06 PM, oliver wrote:
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation?
Yes, if you read R-exts: http://r.research.att.com/man/R-exts.html#Memory-allocation you would know that you're not supposed to use malloc/calloc at all and if you allow interruption ("regular" C code does not) R_alloc does what you asked about.
[...] In the printed (pdf) version of R-exts I found that R_alloc() and S_alloc() and some other functions from section 6.1.1 have return type char*. This seesm to be a relict from the K&R era, because since ANSI C void* is the type for generic pointers. will it be changed in the future, so that R_alloc() will be void* R_alloc() one day? Ciao, Oliver
On Thu, Jun 09, 2011 at 04:42:33PM +0200, oliver wrote:
On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
On Jun 8, 2011, at 8:06 PM, oliver wrote:
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation?
Yes, if you read R-exts: http://r.research.att.com/man/R-exts.html#Memory-allocation you would know that you're not supposed to use malloc/calloc at all and if you allow interruption ("regular" C code does not) R_alloc does what you asked about.
[...] In the printed (pdf) version of R-exts I found that R_alloc() and S_alloc() and some other functions from section 6.1.1 have return type char*. This seesm to be a relict from the K&R era, because since ANSI C void* is the type for generic pointers. will it be changed in the future, so that R_alloc() will be void* R_alloc() one day?
[...] ..and btw: when casting to (void*) instead of mytype* (as is seen on page 122 of "Writing R Extensions" (2011-04-13) t's much better. The the pointer is generic and will automatically be correctly assigned to the left hand side. But better would be of course to avoid any casts and make the return type of the alloc-functions void*. Ciao, Oliver