digitalmars.D.learn - How to destroy a shared struct.
- Marco Leise (16/16) Jan 26 2014 Since shared hasn't change much in the last years, I assume it
- Benjamin Thaut (10/24) Jan 26 2014 I ran into this issue some time ago too.
- Marco Leise (7/33) Jan 28 2014 *nod*
Since shared hasn't change much in the last years, I assume it is somewhat accepted in its current state. My understanding is that if something cannot be attributed to a single thread, it is "shared". So far so good. Now I wrote an object pool struct with two properties: it can be used by multiple threads during its lifetime and this(this) is disabled. Logically the struct is both created and destroyed while only the creator thread (which holds the data) has access to it and there is no two ways about it. An object can only be destroyed when it is no longer shared. Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition? -- Marco
Jan 26 2014
On Sunday, 26 January 2014 at 17:15:10 UTC, Marco Leise wrote:Since shared hasn't change much in the last years, I assume it is somewhat accepted in its current state. My understanding is that if something cannot be attributed to a single thread, it is "shared". So far so good. Now I wrote an object pool struct with two properties: it can be used by multiple threads during its lifetime and this(this) is disabled. Logically the struct is both created and destroyed while only the creator thread (which holds the data) has access to it and there is no two ways about it. An object can only be destroyed when it is no longer shared. Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition?I ran into this issue some time ago too. https://d.puremagic.com/issues/show_bug.cgi?id=8295 Walter stated in a discussion on the newsgroup that this is by design. It basically came down to, that shared structs should not be destroyed ... Although I really don't agree with this, it should be fixed. In my opinion it should not be neccessary to have a shared destructor, because as soon as it is destroyed, it is no longer shared. So no special shared destructor should be neccessary.
Jan 26 2014
Marco Leise <Marco.Leise gmx.de> Am Sun, 26 Jan 2014 21:36:58 +0000 schrieb "Benjamin Thaut" <code benjamin-thaut.de>:On Sunday, 26 January 2014 at 17:15:10 UTC, Marco Leise wrote:*nod* But you must have misunderstood Walter. Keeping shared structs alive forever certainly doesn't work. :p -- MarcoSince shared hasn't change much in the last years, I assume it is somewhat accepted in its current state. My understanding is that if something cannot be attributed to a single thread, it is "shared". So far so good. Now I wrote an object pool struct with two properties: it can be used by multiple threads during its lifetime and this(this) is disabled. Logically the struct is both created and destroyed while only the creator thread (which holds the data) has access to it and there is no two ways about it. An object can only be destroyed when it is no longer shared. Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition?I ran into this issue some time ago too. https://d.puremagic.com/issues/show_bug.cgi?id=8295 Walter stated in a discussion on the newsgroup that this is by design. It basically came down to, that shared structs should not be destroyed ... Although I really don't agree with this, it should be fixed. In my opinion it should not be neccessary to have a shared destructor, because as soon as it is destroyed, it is no longer shared. So no special shared destructor should be neccessary.
Jan 28 2014