With the existing universe of UNIX semantics, copy on write for
substrings could be built tediously by creating a new MAP_PRVIATE map
of the same object as the parent. This would be reasonable only in
the cases that the syscall overhead was a worthwhile trade against
the memory copy and:
* the parent map was MAP_SHARED and msync can be called
* the parent map was MAP_PRIVATE and making a new MAP_PRIVATE copy
of the parent object complete with the parent's edits is feasible
I'm not really excited about either of these. Some UNIX kernels are
drifting towards finer programmer control over virtual memory that
might make it reasonable to get this in other ways.
For instance, we can imagine a mmapable pseudo-file (like /proc/xxx/
mem on linux) that would allow us to build a MAP_PRIVATE copy of
something we already had in core. For very large strings, the syscall
penalty might be worthwhile. In other cases, building a MAP_SHARED
copy of a substring might let us preserve the existing sharing
semantics of substrings together with an ability to do partial gc on
the parent string.
On Dec 4, 2006, at 10:17 PM, Kevin Ryde wrote:
Neil Jerram <[EMAIL PROTECTED]> writes:
Yes from me; it sounds interesting and useful.
Me too.
Stringbufs have room for another flag that could say they're mmaps
(and hence should free with munmap).
I suppose a string is only good while strings are uninterpreted
8-bits. When they're some encoding I guess it has to be u8vectors or
whatever r6rs introduces.
One thing to contemplate if using strings would be how the string
copy-on-write stuff should work. If file contents are changing then
you might not want `substring' to defer the copy (yet most of the time
you probably do want to defer).
_______________________________________________
Guile-user mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-user
_______________________________________________
Guile-user mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-user
