You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The _mmap_js implementation in syscalls.cpp has a TODO:
// TODO: handle non-private mmaps. Those can be optimized in interesting ways
// like avoiding an allocation and a copy as we do below (whereas a
// private mmap is always a copy into a new, private region not shared
// with anything else).
It also asserts that the flags contain MAP_PRIVATE. We don't need to fully address the optimizations in the TODO yet, but we do need to do better than asserting on MAP_SHARED.
The text was updated successfully, but these errors were encountered:
We could support MAP_SHARED on MemoryFile in the simple case where it is not reallocated. That is basically what we supported in the old JS FS. Anything more would probably be quite hard, though.
Before working on this I'll try to collect data on how useful the limited form is. I'm not sure it's been used much in the old FS - we've normally recommended people to not use MAP_SHARED at all (and use features we can fully support).
Good find, @past-due! It looks like the implementation of __map_file also closes the file descriptor right after mapping, so in the current implementation that ties mappings to fds, there's no way that modifications can make it back to the file.
The
_mmap_js
implementation in syscalls.cpp has a TODO:It also asserts that the flags contain
MAP_PRIVATE
. We don't need to fully address the optimizations in the TODO yet, but we do need to do better than asserting onMAP_SHARED
.The text was updated successfully, but these errors were encountered: