GNU Astronomy Utilities - Tasks: task #14292, Delete .gnuastro directory after...
You are not allowed to post comments on this tracker with your current authentication level.
task #14292: Delete .gnuastro directory after mmap'd file is removed
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Wed 28 Dec 2016 03:12:30 PM UTC | ||
Should Start On: | Tue 27 Dec 2016 03:00:00 PM UTC | Should be Finished on: | Tue 27 Dec 2016 03:00:00 PM UTC |
Category: | All Gnuastro | Priority: | 5 - Normal |
Item Group: | Enhancement | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Open |
Effort: | 0.00 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-758e.
Corresponding source code
As part of task #14245, we are moving the internal representation of arrays/data to a generic gal_data_t type. As discussed in that task, it will allow arrays of any dimensionality or type to be passed, and read/written easily (the FITS functions have already been changed to read and write in this structure, and I am busy working on txt tables now).
One other capability of this structure is in dealing with large files: it is not uncommon for data-sets to be larger than a few Giga-bytes, so they can easily fill the RAM of normal computers. To deal with this situation, we have defined the `--minmapsize' option (which is a common option to all programs in this branch). Through it, the users can set the minimum number of bytes in an array of the dataset for it to be mmap'ed (in the hdd/ssd, and not kept in the RAM) instead of being kept in the RAM. It is certainly slower to work outside the RAM, but a slower program is better than one that crashes because of no memory.
Files need to be created to mmap the array. What we do now is to make a randomly named file in the `.gnuastro' directory of the process's working directory. If the working directory doesn't have a `.gnuastro' directory, it will be created. Once the mmap'd memory is no longer needed, that randomly named file is deleted (its name is stored in `mmapname' variable of `gal_data_t'). But the `.gnuastro' directory will remain.
With this task, I wanted to suggest the removal of the `.gnuastro' directory after we remove the mmap file (if it becomes empty ofcourse).