lablgtk missing macros to live in harmony with the garbage collector

Felix Ruess <[email protected]> Tue, 27 Jan 2015 19:52:50 +0100
Newsgroups gmane.comp.lang.ocaml.lib.gtk
Message-ID <CAEc+GFe56dATzks_dSFmESb4PoGZqb6NgoZ4wVF4a1CH=Rti7w@mail.gmail.com>
--===============1419856751560806405==
Content-Type: multipart/alternative; boundary=047d7b874e08fab65b050da6c282

--047d7b874e08fab65b050da6c282
Content-Type: text/plain; charset=UTF-8

Hi guys,

I noticed that our applications seem to use more and more memory the longer
they run.
Profiling it, it looks like most of it is coming from closures that use
GObj and GtkSignal.

It looks like most parts of lablgtk don't properly use the CAMLparam,
CAMLreturn, etc macros that are described here:
http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#sec440
Fixing a similar issue in some of our code interfacing with C made a HUGE
difference.

E.g. the ml_g_signal_override_class_closure function in ml_gobject.c does
not use these macros...
Any particular reason for that? Am I missing something here, or is that a
bug (or rather lots of bugs)?

Cheers, Felix

--047d7b874e08fab65b050da6c282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>Hi guys,<br><br></div>I=
 noticed that our applications seem to use more and more memory the longer =
they run.<br></div>Profiling it, it looks like most of it is coming from cl=
osures that use GObj and GtkSignal.<br><br></div>It looks like most parts o=
f lablgtk don&#39;t properly use the CAMLparam, CAMLreturn, etc macros that=
 are described here: <a href=3D"http://caml.inria.fr/pub/docs/manual-ocaml/=
intfc.html#sec440">http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#se=
c440</a><br></div>Fixing a similar issue in some of our code interfacing wi=
th C made a HUGE difference.<br><br></div>E.g. the ml_g_signal_override_cla=
ss_closure function in ml_gobject.c does not use these macros...<br></div>A=
ny particular reason for that? Am I missing something here, or is that a bu=
g (or rather lots of bugs)?<br><br></div>Cheers, Felix<br></div>

--047d7b874e08fab65b050da6c282--

--===============1419856751560806405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Lablgtk-list mailing list
[email protected]
https://lists.ocamlcore.org/cgi-bin/listinfo/lablgtk-list

--===============1419856751560806405==--