SCM

[#2428] use external pointers to refer to objects backed by R_raster_tmp files

Date:
2012-12-07 23:55
Priority:
3
State:
Open
Submitted by:
Oliver Soong (osoong)
Assigned to:
Nobody (None)
Product:
None
Operating System:
None
Component:
None
Summary:
use external pointers to refer to objects backed by R_raster_tmp files

Detailed description
With a finalizer that unlinks the files, I think R will delete the temporary R_raster_tmp object when the last referencing R object is gc'ed. I believe this is one of the purposes of the finalizers and external pointers.

Comments:

Message  ↓
Date: 2012-12-11 22:00
Sender: Oliver Soong

Personally, I've never had to use external pointers in my own code. RODBC uses them and it's cited as an example in Writing R Extensions 5.13, so I'll use it as an example as well.

> channel <- odbcConnectExcel("test.xls")
> rm(channel)
> invisible(gc())
Warning: closing unused RODBC handle 1
> channel <- odbcConnectExcel("test.xls")
> channel2 <- channel
> rm(channel)
> invisible(gc())
> rm(channel2)
> invisible(gc())
Warning: closing unused RODBC handle 2

I imagined the external pointer would just point to the filename. The read code would have to be modified to extract the string first, but then everything else should be the same. The external pointer gets copied around, but it's not finalized until the last reference is destroyed, as with channel and channel2. The finalizer code would delete the temporary file, and would get called on exit. If it's coded similarly to how RODBC works, it should be safe as long as nobody hunts down the temporary file and creates a regular file reference to it, but nobody should be doing that in the first place. I don't know how much magic is coded in RODBC to get it to work this way, but it should be somewhat easier with example code.

Anyway, just a thought. I've been just writing my code to avoid creating these temporary objects, and I think it's forcing me to write more efficient code anyway.

Date: 2012-12-11 21:24
Sender: Robert Hijmans

Yes, but the files are not accessed through an external pointer, and even if they were, different Raster objects could use different pointers referring to the same file.

Attached Files:

Changes

No Changes Have Been Made to This Item

Thanks to:
Vienna University of Economics and Business Powered By FusionForge