On 11-03-14 02:04 PM, Florian Weimer wrote:
* Marijn Haverbeke:
Uhm. How do you plan to deal with unmapping the file?
Have an obj that represents the lifetime of the mapping, with a
destructor that unmaps it.
Yes, but vec[u8] would have to keep a reference to it, to prevent
premature unmapping. Would that fit into the existing type system?
Nope. The way to do this with the *existing* type system is to not-unify
the ideas of vec[u8] and vbuf. Wrap a vbuf in an obj that unmaps on
destruction, access it through obj methods.
The way to do this in the *future* type system involves, probably, a
small number of efficiency-oriented changes we were discussing back in
the fall idly, but haven't gotten around to implementing (or even
coherently writing-up) due to the bootstrapping task taking focus. The
techniques involve some combination of:
- Make a vec have a pointer to its data rather than holding it inline,
to facilitate the next item.
- Give a vec have an inline and out-of-line region, and make both
uniquely owned so there's no refcounting. Put in a @ if you want
that.
- Split the concept of a dtor out of an obj to a separate 'resource'
type, a transparent nominal type that attaches a dtor to a value and
otherwise provides no other services. Can only be applied to non-GC
values. Permits things like "native pointer + dtor" that doesn't
require a full heap allocation + vtbl.
We don't have enough of this machinery lying around yet, sadly, but have
some background plans for some-or-all of them.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
