On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio
wrote:
On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
When does invalidMemoryOperationError happen and how do you
avoid it?
Typical example:
using (a slightly outdated version of) gfm library, I have few
gfm objects lying around on which I forget to call a close()
function. When the GC collects them the destructor runs
close(), which in turn calls for some allocation (e.g:
allocates for a string to send to the logger),
invalidMemoryOperationError pops up.
This usually only happens at the end of execution, sometimes
however it happens randomly during program execution due to the
randomness of GC operations.
The only way out of this is manually closing everything
correctly. I.e: I'm almost back to C++ manual memory
management. Catching the exception is an unsatisfactory
solution because I would still be leaking resources[1]. If
possible, things are made even worse in that RefCounted doesn't
work for classes, but that you can work around that (class
instance into refcounted struct, not really elegant and
requires lots of discipline, since it's easy to escape an extra
reference).
[1] For everyone who doesn't know: non trivial destructors are
really useful in gfm because it wraps some C libraries, and
cleaning up C allocated resources is usually important. Proper
execution of gfm's close() for every class would be ideal.
Yeah the current situation force much discipline vs C++, and I
made it worse by having class destructors call close() which turn
things to work sometimes only by chance.
I think more and more that I should have class destructors that
don't call close(), and simply don't do anything.
It's what glamour does
(https://github.com/Dav1dde/glamour/blob/master/glamour/shader.d#L207)
and it seems way more practical. Especially since destructors
called by GC would release resources from the wrong thread, at
the wrong moment, etc.
It would be great if we settle on a name for this releasing
function, whether it is close(), release(), dispose()... it seems
it is a blocker for owning pointers of class instances.