On 10-12-16 02:29 PM, Rafael Ávila de Espíndola wrote:
Another question I found while reading the manual:
Another good catch :)
The manual says that immutable boxes are shared and are destroyed when the reference count gets to zero. The problem, if I understand it correctly, is that the destructors are user visible, but the creation of immutable shared boxes is not in all cases.
Indeed. There's also a further problem that in some cases we can't really find a context in which to run a dtor (such as a dropped message), so we'd need some kind of scavenger task.
When sending something over a channel the runtime can increment the reference copy or do an actual copy (if going to another os thread for example). If it copies now the destructors are run twice. We discussed some options *) Require that resources be reference counted. Really expensive, since the reference count would have to be atomic. *) Distinguish copyable and non-copyable mutable data. A destructor can then only get non copyable data and only copyable data can be sent over a channel (short of a move). Is the second option in line with what you had in mind?
There are a few less-savoury options as well (multiple-destruction, etc.) but I agree with your judgment of the best cases. Our current proposed (but only weakly sketched-out) approach is the latter: distinguish the copyable from the non-copyable. It's not described yet in the manual, nor enforced in the compiler (though it's at least semi-calculated by the bootstrap compiler). The characteristic of types is referred to as their "abstractness", and both closures and objects are considered abstract in the current logic.
Patrick has some thoughts about splitting the concept of a destructable resource out into an orthogonal concept, independent of objects (so that it would not always incur a vtbl+heap allocation). Before we go too far down the road of prohibiting *all* objects from channels, we should probably think more about this scheme, and/or differentiating objects with dtors from those without.
(There are other reasons for potentially making obj and fn types non-transmittable, mostly to do with transmitting data between processes that might have different runtime-linkage choices, thus have different vtbl and fn implementations. We haven't fixed compatibility rules on IPC yet to clarify this. Feel free to chew on this topic as well :)
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
