You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Wes McKinney (JIRA)" <ji...@apache.org> on 2017/01/22 21:21:26 UTC

[jira] [Updated] (ARROW-494) [C++] When MemoryMappedFile is destructed, memory is unmapped even if buffer referecnes still exist

     [ https://issues.apache.org/jira/browse/ARROW-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wes McKinney updated ARROW-494:
-------------------------------
    Assignee: Wes McKinney

PR: https://github.com/apache/arrow/pull/298

> [C++] When MemoryMappedFile is destructed, memory is unmapped even if buffer referecnes still exist
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ARROW-494
>                 URL: https://issues.apache.org/jira/browse/ARROW-494
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: C++
>            Reporter: Wes McKinney
>            Assignee: Wes McKinney
>
> I'd like to see if there is some way to "protect" the memory map from premature destruction. This is a slight artifact of MemoryMappedFile's implementation sharing code with normal on-disk files (which read into allocated memory), i.e. the `Close` function unmaps the memory and closes the file handle. This would amount to creating a Buffer subclass that retains ownership of the file descriptor and memory map, so that if any Buffer still references the memory map, then `MemoryMappedFile::Close` will not unmap the memory or close the file. But then the unmapping / file close would need to happen when the last Buffer reference is destroyed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)