D wrapper classes leak memory. Next steps?

[Marco Leise via Digitalmars-d]

Am Fri, 31 Oct 2014 06:44:48 +0200
schrieb ketmar via Digitalmars-d <digitalmars-d at puremagic.com>:

> On Fri, 31 Oct 2014 05:38:48 +0100
> Marco Leise via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> 
> > GtkD wraps all the objects in Gtk. In callbacks like "onDraw",
> > when they are called often, this creates heaps of tiny wrapper
> > objects around huge data from C libraries. Eventually system
> > memory is exhausted and the computer slows down and eats into
> > swap. So should we add a "run garbage collector" button to
> > every application to clean those up? Seems rather silly.
> > 
> > The GC should stick to its own memory and not try to manage
> > resources it doesn't understand. Reference counting applies to
> > external and system resources much better. To date neither the
> > language nor Phobos can ref count classes. And even with
> > library support it is not likely that it will get used widely,
> > because plain classes are so much easier (also on the eyes).
> > 
> > The extent of this is pretty huge. There are many D wrapper
> > libraries that build on classes and mimic what is available
> > for C++ or Python. Issues like this make D appear like a toy
> > language. How would one write a big desktop application when
> > a simple animation can exhaust system memory in seconds ?
> why do you blaming GC for what seems to be a library author's fault?
> that was the library author who chooses to wrap externally-managed
> objects in GC objects, and creating alot of throwaway classes for that.

Can't blame the author when there is no other choice in the
language than to use tracing GC with inheritance.

> alas, we haven't Skynet at the hand to guess what author really wants.
> 
> p.s. i was never using GtkD, so i don't know if it's really doing the
> things you wrote or not, i'm just assuming that you are right.

To be fair there is an overload for addOnDraw that takes a
delegate that has a Scoped!Context as parameter, but I cannot
use that with delegates marked as nothrow since Scoped's dtor
isn't nothrow. Which prompts the question again how to deal
with exceptions in dtors. All D delegates called from the C
side have to be nothrow though, because neither can druntime
deal with GCC's amd64 stack (omit-frame-pointer) nor is the C
side necessarily prepared for exceptions.

-- 
Marco