From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q04JbwKI017258 for ; Wed, 4 Jan 2012 20:37:58 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAPupBE8SB0QimWdsb2JhbABDggWqZSIBAQEBAQgLCwcUJYFyAQEEAXkFCwtGVwaIDaxAiQWMDwSIOJ8e X-IronPort-AV: E=Sophos;i="4.71,457,1320620400"; d="scan'208";a="137868992" Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Jan 2012 20:37:53 +0100 X-AuditID: 12074422-b7fd66d0000008f9-fc-4f04aa9095a5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 6E.A6.02297.09AA40F4; Wed, 4 Jan 2012 14:37:52 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q04JbpdJ019076; Wed, 4 Jan 2012 14:37:52 -0500 Received: from localhost (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.9.64.11]) (authenticated bits=0) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q04JbpSf028441; Wed, 4 Jan 2012 14:37:51 -0500 (EST) Message-Id: <201201041937.q04JbpSf028441@outgoing.mit.edu> To: Adrien cc: Caml List In-reply-to: References: <96F225D0-B458-4E25-BE34-3976989984B2@ezabel.com> <20120101124454.GA12851@annexia.org> <1453C993-CFD2-41AD-9611-A90398E560EC@inria.fr> Comments: In-reply-to Adrien message dated "Wed, 04 Jan 2012 19:48:38 +0100." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Wed, 04 Jan 2012 14:37:50 -0500 From: John Carr X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUixCmqrDthFYu/weyX7BYN0w6zW3zasYHF gclj56y77B6TXhxiCWCK4rJJSc3JLEst0rdL4MpYdGAFa8EXjorbL9+wNTBOZu9i5OSQEDCR +Nz8mhnCFpO4cG89WxcjF4eQwD5Gie8XW5hAEkIC6xkl1uwxhEj8Z5T4sPs6C0iCV8BKYtOe pawgtoiAksSmT+uAbA4OZiD7wVY5kLCwgLXE1Msv2UHCnAKBErf6JSDGnGOS2Ld7LxtIDbNA pkT3xL+MEEfoSnxcNBPsOBYBVYlvzQfA4mwCshKP2rsYJzDyL2BkWMUom5JbpZubmJlTnJqs W5ycmJeXWqRrqpebWaKXmlK6iREURuwuSjsYfx5UOsQowMGoxMP7sIHFX4g1say4MvcQoyQH k5Ior/8KoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3q0zgXK8KYmVValF+TApaQ4WJXFeda13 fkIC6YklqdmpqQWpRTBZGQ4OJQleLWC8CAkWpaanVqRl5pQgpJk4OEGG8wANf7cSZHhxQWJu cWY6RP4Uo6KUOO9vkIQASCKjNA+uFxbnrxjFgV4R5tUEWcEDTBFw3a+ABjMBDY4SARtckoiQ kmpgLF6o99P4bElKucWF0xoX1ks7NBoZs3E+ibpgdvXXq3MTq1jzg+wKvKz4dKJvsqSHKl91 rKuM8rygskNtpa7/VOmeD62LP0cLmv/9YRB4UI7Ly+ndBFOxooLDc9SVk0Jv3l030X3qPL2d t4WlZXVc/S9GPfa5r5/jKZy4tb2pfMYnHSOGtw1KLMUZiYZazEXFiQA+v/s1zgIAAA== Subject: Re: [Caml-list] Understanding usage by the runtime > There is however something to do. Quoting lablgtk's README: > > IMPORTANT: Some Gtk data structures are allocated in the Caml heap, > > and their use in signals (Gtk functions internally cally callbacks) > > relies on their address being stable during a function call. For > > this reason automatic compation is disabled in GtkMain. If you need > > it, you may use compaction through Gc.compact where it is safe > > (timeouts, other threads...), but do not enable automatic compaction. > > I've never really understood why it worked: I'm surprised the GC would > update addresses stored in the C side of GTK. I think the problem is, a C function can invoke a callback that calls ocaml code that moves the object being operated on by the C function. Because the C function is precompiled it does not register its copy of the pointer as a GC root. When the callback returns the C function's pointer is invalid. This should be fixable with another level of indirection. Finalization can free the C object. I infer from reading the source that the extra level of indirection is considered an unacceptable penalty.