|Posted by crimaniak|
in reply to Joakim
Posted in reply to Joakim
On Saturday, 15 July 2017 at 18:14:13 UTC, Joakim wrote:
>> core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid memory operation
> See the wiki page about this:
> If you can't do all that, look for places you might be allocating in a destructor. The recent GC allocation flag -vgc might help:
Yes, I found it already and make documentation proposition about https://issues.dlang.org/show_bug.cgi?id=17642
Then it turned out that it was more difficult to avoid this problem than to find the cause. Yes, I have a heavy cleanup in the destructor and I can't definitely make this cleanup @nogc. So first I tried to make problematic object instances RefCounted. In my case, it means change ClientController[string] to RefCounted!ClientController[string] and create an object by lib interface, not by new. I have to change ClientController from object to struct because automem can't work with the object. I hunted all extra copies of these objects and kill them all, so now I sure there are no copies except the main container. I tried different libraries from std.typecons.RefCounted to automem. And I fail to make it _really_ reference counted. It's not deleted when I delete it from the container. Every time it's collected by GC and application is dropped. So I decided that in the container itself. Obviously, the associative array does not delete the elements themselves on demand, but loses them and gives them to the garbage collector.
I didn't find any map or multimap @nogc container so I make the ugly solution: I move all destruction to method destructMe() and in ~this() now is just assert(destructMeIsCalled). And now I have to call manually destructMe() before object removing. It seems it works. I'm wondering if there is a less ugly way to have the map of reference counted objects.