On 09/08/2015 08:03 AM, Mike Hearn wrote:
If you're already doing this, why not skip the level of indirection and mprotect the entire mapped region to PROT_NONE when the user unmaps? ....... Then you do the real unmap when the buffer is GC'd (maybe via Cleaner).Because the reason users are working around this is Windows, where they need the ability to do: buffer.unmap(); file.delete(); If the unmap is still asynchronous it doesn't solve the problem.
So Windows has no operation which can remap a previously mapped section of memory to something else? (say, just a block of non-access memory)
Note that such an operation has to be atomic with respect to all other operations which affect the address space of the process (or at least, which may randomly choose an address in memory at which to create new mappings), but not with respect to anything else really. The point of the remapping is to continue to reserve the address space, without actually referencing what was there before (thus dodging file lock issues). No physical or virtual memory need actually be reserved for such a mapping.
-- - DML
