digitalmars.D - RAII is misleading
- duff (6/6) Nov 24 2015 I've discovered this when working on a kind of "fat pointer"
- duff (9/15) Nov 24 2015 You would like to serialize a tree of object ?
I've discovered this when working on a kind of "fat pointer" system. The "RAII" term is misleading, it tends to let people think that the one who initializes a resource is its owner. The reality is different. The real owner of a resource is the one who see it "as valid" for the first time.
Nov 24 2015
On Tuesday, 24 November 2015 at 15:14:16 UTC, duff wrote:I've discovered this when working on a kind of "fat pointer" system. The "RAII" term is misleading, it tends to let people think that the one who initializes a resource is its owner. The reality is different. The real owner of a resource is the one who see it "as valid" for the first time.You would like to serialize a tree of object ? Using ReferenceCounting: which one has to write the properties of an object that's only a reference ? Using ReferenceCounting: let's say that the last object who has a referenced object serialiazes it, there's no guarantee that when the soft run again his reference is already set... The only way to do this correctly is to use system of ownership rather than RC system.
Nov 24 2015
On Tuesday, 24 November 2015 at 16:12:23 UTC, duff wrote:On Tuesday, 24 November 2015 at 15:14:16 UTC, duff wrote:One approach is to start serialization at the root node, annd whoever sees a node first could serialize it, and all references it contains, recursively. When an object is serialized, its memory address or unique ID of some kind could be added to a hashtable. Then, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again. If we were talking about C++, I would say to use the object address as the unique ID - shared_ptr<T>::get(). Im not sure if D's RefCounted has an equivalent function. For deserializing, you could do two passes. First, read all nodes into a table, which you can index by the node's old memory address, and second, build the tree and resolve referenes to the new nodes' addresses. I'm not claiming this is the best approach, but it has worked for me in the past. BitI've discovered this when working on a kind of "fat pointer" system. The "RAII" term is misleading, it tends to let people think that the one who initializes a resource is its owner. The reality is different. The real owner of a resource is the one who see it "as valid" for the first time.You would like to serialize a tree of object ? Using ReferenceCounting: which one has to write the properties of an object that's only a reference ? Using ReferenceCounting: let's say that the last object who has a referenced object serialiazes it, there's no guarantee that when the soft run again his reference is already set... The only way to do this correctly is to use system of ownership rather than RC system.
Nov 24 2015
On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:Then, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again.But this doesn't give the guarentee that the real citizen who responsible to tell the client "hey i've got the ref" can do it. With RC, the real owner may not know that his resource is stolen by a children.
Nov 24 2015
On Tuesday, 24 November 2015 at 18:22:12 UTC, duff wrote:On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:The way that I was dealing with this at the time was requesting resources(files) from a shared repository by name. The repository would either load the file and instantiate the appropriate object, or return the object if it already existed. So, no node in the graph ever really owned a resource. All resources were owned by one central repository. Now, this was only enforced by convention, so I suppose someone could call delete on the shared_ptr's internal pointer, but making this strictly enforced through language features is difficult, if at all possible without major comprimises. There is some discussion about this idea in the dlang Study forum. They're trying to figure out how to implement ref counting in D in a totally safe way(impossible to currupt memory). I think that some major comprimises will have to be made, and I personally wohld rather deal with this issue through good coding conventions. BitThen, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again.But this doesn't give the guarentee that the real citizen who responsible to tell the client "hey i've got the ref" can do it. With RC, the real owner may not know that his resource is stolen by a children.
Nov 24 2015
bitwise <bitwise.pvt gmail.com> On Tuesday, 24 November 2015 at 19:22:46 UTC, bitwise wrote:On Tuesday, 24 November 2015 at 18:22:12 UTC, duff wrote:I should add that the repository stored references to the resources as weak_ptrs so when the resources went out of scope, they would be deleted. Similar systems may also choose to keep these resources around, even with a ref count of zero, and only delete them when more new resources were requested and memory ran low. This would be a much more comicated approach though.On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:The way that I was dealing with this at the time was requesting resources(files) from a shared repository by name. The repository would either load the file and instantiate the appropriate object, or return the object if it already existed. So, no node in the graph ever really owned a resource. All resources were owned by one central repository. Now, this was only enforced by convention, so I suppose someone could call delete on the shared_ptr's internal pointer, but making this strictly enforced through language features is difficult, if at all possible without major comprimises. There is some discussion about this idea in the dlang Study forum. They're trying to figure out how to implement ref counting in D in a totally safe way(impossible to currupt memory). I think that some major comprimises will have to be made, and I personally wohld rather deal with this issue through good coding conventions. BitThen, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again.But this doesn't give the guarentee that the real citizen who responsible to tell the client "hey i've got the ref" can do it. With RC, the real owner may not know that his resource is stolen by a children.
Nov 24 2015
On Tuesday, 24 November 2015 at 19:22:46 UTC, bitwise wrote:On Tuesday, 24 November 2015 at 18:22:12 UTC, duff wrote:I know that there is a study group. And it's not the first time I post this: http://www.reactiongifs.com/r/dnd.gif because manual memory managment is the stuff.On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:The way that I was dealing with this at the time was requesting resources(files) from a shared repository by name. The repository would either load the file and instantiate the appropriate object, or return the object if it already existed. So, no node in the graph ever really owned a resource. All resources were owned by one central repository. Now, this was only enforced by convention, so I suppose someone could call delete on the shared_ptr's internal pointer, but making this strictly enforced through language features is difficult, if at all possible without major comprimises. There is some discussion about this idea in the dlang Study forum. They're trying to figure out how to implement ref counting in D in a totally safe way(impossible to currupt memory). I think that some major comprimises will have to be made, and I personally wohld rather deal with this issue through good coding conventions. BitThen, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again.But this doesn't give the guarentee that the real citizen who responsible to tell the client "hey i've got the ref" can do it. With RC, the real owner may not know that his resource is stolen by a children.
Nov 24 2015
On Tuesday, 24 November 2015 at 19:37:33 UTC, duff wrote:On Tuesday, 24 November 2015 at 19:22:46 UTC, bitwise wrote:I had my way, the first thing I would do is get rid of safe and shared ;) Its not that I don't think the general idea of making the language safe is good, but there is just so much that can go wrong in a systems programming language, its like throwing glasses of water at a burning house instead of just calling the fire department.. Never underestimate the resourcefulness of a bad programmer!On Tuesday, 24 November 2015 at 18:22:12 UTC, duff wrote:I know that there is a study group. And it's not the first time I post this: http://www.reactiongifs.com/r/dnd.gif because manual memory managment is the stuff.On Tuesday, 24 November 2015 at 17:03:47 UTC, bitwise wrote:The way that I was dealing with this at the time was requesting resources(files) from a shared repository by name. The repository would either load the file and instantiate the appropriate object, or return the object if it already existed. So, no node in the graph ever really owned a resource. All resources were owned by one central repository. Now, this was only enforced by convention, so I suppose someone could call delete on the shared_ptr's internal pointer, but making this strictly enforced through language features is difficult, if at all possible without major comprimises. There is some discussion about this idea in the dlang Study forum. They're trying to figure out how to implement ref counting in D in a totally safe way(impossible to currupt memory). I think that some major comprimises will have to be made, and I personally wohld rather deal with this issue through good coding conventions. BitThen, during recursive serialization, if you found an object which was already in the table, you wouldn't serialize it again.But this doesn't give the guarentee that the real citizen who responsible to tell the client "hey i've got the ref" can do it. With RC, the real owner may not know that his resource is stolen by a children.
Nov 24 2015