From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 46D207FE07 for ; Wed, 3 Feb 2016 14:49:50 +0100 (CET) IronPort-PHdr: 9a23:9s+GTxaUwXu5zFvGJWy8+SP/LSx+4OfEezUN459isYplN5qZpM25bnLW6fgltlLVR4KTs6sC0LqJ9fm+Ejdbqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0osOYOF4ArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIYTGZn9Ko84V71DEDM+M1cVesLmr1GXRguV52AAVX0W1BpPDgfI9jnmQ9L7vzH+t+w71CTMeYW8RrkxXXGm7rx3YB7ukiYOcTAjuimDgcV1iOdfoQm9jx152Y/dJo+PYqlQZKTYKPEXX2dEX8sZey1EA4W7J98NA+sEPOBfh4v0oVYVsQGzCBXqD+TqnGwbzkTq1LE3hrxyWTrN2xYtSooD Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=jdimino@janestreet.com; spf=Pass smtp.mailfrom=jdimino@janestreet.com; spf=None smtp.helo=postmaster@mxout1.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jdimino@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="jdimino@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jdimino@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="jdimino@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CJAQDmBLJWnHDIaSZehAxtBohVsSGBZSGFbAKBPwc5EwEBAQEBAQEBEAEBAQEBBhYJT4ItghUBAQMBEhEEGQEBOAQLCQILNwICIhIBBQEcBgESCBMHh3EIAwuTUo8/gTE+MYpNZ4RAAQSKQwEBAQEGAQEBAQEBAQESBgqGCIQ3hzKBOpZ2hUmIBIFbSoxMhXCEfoIWER6BDQ8TAYI1DREIgUhqAYlqAQEB X-IPAS-Result: A0CJAQDmBLJWnHDIaSZehAxtBohVsSGBZSGFbAKBPwc5EwEBAQEBAQEBEAEBAQEBBhYJT4ItghUBAQMBEhEEGQEBOAQLCQILNwICIhIBBQEcBgESCBMHh3EIAwuTUo8/gTE+MYpNZ4RAAQSKQwEBAQEGAQEBAQEBAQESBgqGCIQ3hzKBOpZ2hUmIBIFbSoxMhXCEfoIWER6BDQ8TAYI1DREIgUhqAYlqAQEB X-IronPort-AV: E=Sophos;i="5.22,391,1449529200"; d="scan'208,217";a="200934276" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 14:49:49 +0100 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1aQxoa-0003EI-8p for caml-list@inria.fr; Wed, 03 Feb 2016 08:49:48 -0500 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BWsgV8-AAACko-HN; 2016-02-03 08:49:48.231361-05:00 Received: from mail-io0-f180.google.com ([209.85.223.180]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1aQxoa-0000fV-4I for caml-list@inria.fr; Wed, 03 Feb 2016 08:49:48 -0500 Received: by mail-io0-f180.google.com with SMTP id g73so55515309ioe.3 for ; Wed, 03 Feb 2016 05:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TQznh82k/bogJWXdOBN+vPHbbyOWGoCXWViAa2oJdKc=; b=K/2RhiTBamuMd8unZdWzUh5EAaEZ6qC+HURnsssPHxRW4F/4ftNsBRPPvC24upA59O stK0aGJAmi/gkpWhy5KQmQNdats2NcWVX2Y1FVmEUC+wgkMdzaDiTtW9EjNqs15FKUsL w2ZBTvWpGd0+oMVhcQFpmJlR4L5jOCN0FpNJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TQznh82k/bogJWXdOBN+vPHbbyOWGoCXWViAa2oJdKc=; b=jiGeg1pDkLCGeY8Cg3CgqmQEEwl7jZuzk07Z+fpp6N5MaA1Pw6av9ub2h0X4GWPRYu MLN+MXKTL7Vf5sOL2Cw6J2JSqVRfTqduYkt/71vfwSybyJLA1Mg+4OP82NxfikoE7ICx fQIjauJLOv19T4rKVJ/UfkS4CfzadvBpEZQgs8ScY3D4wV2lD2NWw1kxQvH6xh4hZf4F aa66w9tYOpK2/I/6Ha+A4ahKjQKfyJqANEXC+sUhfAx1WM3MGiTR4xp8uA7n8Letf4ht Dae1SRBWBHm1s2pEXVwuQueqmCW+szvU+2Xdam3XZ/Ceh/LVvaAHgSLIysJQAej84pwI Y1Dw== X-Gm-Message-State: AG10YORznvPCt150LNaRwRpUn/0xHos6PpZ9VaKFNohlU6WCUl3BB4uAX9AdeLVnh8xczgkXdoXZf11zbNEVlEO06xmMhTqrx+yaZ2wfTGpB5MVW36Wr0kQ9NMgwSWv7cPzV0bTZlSHbzOpisOeUr4obhg== X-Received: by 10.107.138.36 with SMTP id m36mr4151777iod.82.1454507387707; Wed, 03 Feb 2016 05:49:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.138.36 with SMTP id m36mr4151758iod.82.1454507387548; Wed, 03 Feb 2016 05:49:47 -0800 (PST) Received: by 10.50.30.193 with HTTP; Wed, 3 Feb 2016 05:49:47 -0800 (PST) In-Reply-To: <56B1EC33.2090303@tu-berlin.de> References: <56B1DC54.1060109@tu-berlin.de> <56B1EC33.2090303@tu-berlin.de> Date: Wed, 3 Feb 2016 13:49:47 +0000 Message-ID: From:Jeremie Dimino To:=?UTF-8?Q?Christoph_H=C3=B6ger?= , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a113ea164289aea052adde420 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Save callbacks from OCaml to C --001a113ea164289aea052adde420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 12:01 PM, Christoph H=C3=B6ger < christoph.hoeger@tu-berlin.de> wrote: > Thanks for your reply, > > Am 03.02.2016 um 12:48 schrieb Jeremie Dimino: > > void g(...) { > > CAMLparam0(); > > CAMLlocal3(ml_t, ml_x, ml_g); > > ... > > CAMLreturn0; > > } > > I tried this before, but it seemed like the GC would still write into > the arguments here. Is the semantics of CAMLparam0 that I might have > additional, unmanaged arguments? CAMLparam0 is for when you have no [value] arguments but have some local [value] variables. CAMLlocalN must be preceded by a CAMLparamY, that's why you need the CAMLparam0. > =E2=80=8BNote that &(user_data->g) must be a GC root as well. Are you > > registering &(user_data->g) with the GC in any way? > > Good question. It _is_ an argument to a function on the other side of > the stack, so in principle it is alive, but could the GC move it? =E2=80=8BYes, it should be alive. However I imagine that in the main C stub= , you have something like this: value blah(value g, ...) { ... user_data->g =3D g; ... } So if the GC ends up moving [g], it needs to know that it must update [user_data->g] to point to the new location. There are several solutions: - if [user_data] only exists for the duration of the [blah] function call, I would suggest to change [user_data->g] to be a [value*] instead: value blah(value g, ...) { =E2=80=8B CAMLparam1(g);=E2=80=8B =E2=80=8B ... user_data->g =3D &g; ... } - if it lives for longer, you need to register [user_data->g] as a global variable, as described in the manual (Rule 4 of http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html). --=20 Jeremie --001a113ea164289aea052adde420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Fe= b 3, 2016 at 12:01 PM, Christoph H=C3=B6ger <christoph.hoeger@tu-berlin.de><= span style=3D"font-family:arial,sans-serif"> wrote:
Thanks for = your reply,

Am 03.02.2016 um 12:48 schrieb Jeremie Dimino:
> void g(...) {
>=C2=A0 =C2=A0CAMLparam0();
>=C2=A0 =C2=A0CAMLlocal3(ml_t, ml_x, ml_g);
>=C2=A0 =C2=A0...
>=C2=A0 =C2=A0CAMLreturn0;
> }

I tried this before, but it seemed like the GC would still write int= o
the arguments here. Is the semantics of CAMLparam0 that I might have
additional, unmanaged arguments?

CAMLpar= am0 is for when you have no [value] arguments but have some local [value] v= ariables. CAMLlocalN must be preceded by a CAMLparamY, that's why you n= eed the CAMLparam0.
=C2=A0

> =E2=80=8BNote that &(user_data->g) must be a GC root as well. A= re you
> registering &(user_data->g) with the GC in any way?

Good question. It _is_ an argument to a function on the other side o= f
the stack, so in principle it is alive, but could the GC move it?

=E2=80=8BYes, it should be alive. = However I imagine that in the main C stub, you have something like this:

valu= e blah(value g, ...)
{
=C2=A0 ...
=C2=A0 user_da= ta->g =3D g;
=C2=A0 ...
}

So if the GC ends up moving [g], it needs to know that = it must update [user_data->g] to point to the new location.
<= div>

There are seve= ral solutions:

- if [user_data] only exists for the duration of the [blah] fu= nction call, I would suggest to change [user_data->g] to be a [value*] i= nstead:

value blah(value g, ...)
{
=E2=80=8B =C2=A0CAMLparam1(g);=E2=80=8B
=E2=80=8B = =C2=A0...
=C2=A0 user_data->g =3D &= ;g;
=C2=A0 ...
}

- if it lives for longer,= you need to register [user_data->g] as a global variable, as described = in the manual (Rule 4 of=C2=A0http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html<= /a>).

--
J= eremie
--001a113ea164289aea052adde420--