From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 40CA27ED7A for ; Tue, 28 Aug 2012 13:48:42 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jonathan@kimmitt.co.uk) identity=pra; client-ip=209.85.213.62; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jonathan@kimmitt.co.uk"; x-sender="jonathan@kimmitt.co.uk"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jonathan@kimmitt.co.uk) identity=mailfrom; client-ip=209.85.213.62; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jonathan@kimmitt.co.uk"; x-sender="jonathan@kimmitt.co.uk"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yw0-f62.google.com) identity=helo; client-ip=209.85.213.62; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jonathan@kimmitt.co.uk"; x-sender="postmaster@mail-yw0-f62.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMCAN6vPFDRVdU+jWdsb2JhbABFqRWRXQgiAQEBAQkJCwkSBiOCIAEBAQQBAQEPAhNHCxALGA0hNAEFAQoSKwkHh1wDDAucNQkDlRMDiViLCIM9gxwDiE+OG40jPoQj X-IronPort-AV: E=Sophos;i="4.80,326,1344204000"; d="scan'208";a="171049510" Received: from mail-yw0-f62.google.com ([209.85.213.62]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Aug 2012 13:48:41 +0200 Received: by yhkk61 with SMTP id k61so5153637yhk.27 for ; Tue, 28 Aug 2012 04:48:39 -0700 (PDT) Received: by 10.52.67.12 with SMTP id j12mr2273128vdt.7.1346154519252; Tue, 28 Aug 2012 04:48:39 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.caml Date: Tue, 28 Aug 2012 04:48:39 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=86.9.119.233; posting-account=JMPJagoAAACXMK_kS4Z5sK6kRCaAl6hy NNTP-Posting-Host: 86.9.119.233 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 86.9.119.233 MIME-Version: 1.0 Message-ID: <506691e7-68e5-4092-a9fc-4cc8711235d2@googlegroups.com> From: jonathan@kimmitt.co.uk To: fa.caml@googlegroups.com Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Thread-private data in C stubs On Monday, 27 August 2012 22:08:18 UTC+1, Andre Nathan wrote: > On Mon, 2012-08-27 at 16:41 -0300, Andre Nathan wrote: >=20 > > Hello >=20 > >=20 >=20 > > I'm writing stubs to a C library uses pthreads and exposes two functions >=20 > > to get and set thread-private data, getpriv(ctx) and setpriv(ctx, p) >=20 > > where ctx is some opaque context object, and p is a void* pointer. >=20 > >=20 >=20 > > What's the best way to deal with this from the stub code, ie., how do I >=20 > > avoid the thread-private data to be garbage collected when the OCaml >=20 > > variable goes out of scope? >=20 > >=20 >=20 > > Since the library in question uses threads internally, this needs to be >=20 > > a thread-safe solution. >=20 >=20 >=20 > For the record, with help from #ocaml, I got it to work like this: >=20 >=20 >=20 > struct priv { >=20 > value v; >=20 > }; >=20 >=20 >=20 > CAMLprim value >=20 > caml_setpriv(value ctx_val, value priv_val) >=20 > { >=20 > CAMLparam2(ctx_val, priv_val); >=20 > context *ctx =3D (context *)ctx_val; >=20 > struct priv *p; >=20 >=20=20=20=20 >=20 > p =3D getpriv(ctx); >=20 > if (p !=3D NULL) { >=20 > caml_remove_global_root(&(p->v)); >=20 > caml_stat_free(p); >=20 > } >=20 >=20 >=20 > p =3D caml_stat_alloc(sizeof(*p)); >=20 > p->v =3D priv_val; >=20 > ret =3D setpriv(ctx, p); >=20 > caml_register_global_root(&(p->v)); >=20 >=20 >=20 > CAMLreturn(Val_unit); >=20 > } >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Caml-list mailing list. Subscription management and archives: >=20 > https://sympa-roc.inria.fr/wws/info/caml-list >=20 > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >=20 > Bug reports: http://caml.inria.fr/bin/caml-bugs Dear Andre, in my view it is needlessly inefficient to create a new global = root for every item which crosses the C-interface. I used a system which us= es dlmalloc to carve up an allocated caml custom block into convenient size= d chunks. Each of these large blocks could be a local root or they could be= chained together from one global root. Another advantage is that subroutin= es written in C that allocate memory do not need to know they are running u= nder caml if dlmalloc is compiled to replace the system malloc. The one dow= nside is that it is difficult to track when the global blocks are ready to = be released. My impression is ocaml runtime would get very slow if there we= re huge numbers of global roots.