From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id A4AA8BC37 for ; Wed, 24 Feb 2010 22:22:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQCAM4mhUvRVdzgkGdsb2JhbACRIYloCBUBAQEBBwsMBxMDH6xvgVmFIy2ISQEBAwWEbQQ X-IronPort-AV: E=Sophos;i="4.49,534,1262559600"; d="scan'208";a="45536850" Received: from mail-fx0-f224.google.com ([209.85.220.224]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Feb 2010 22:22:07 +0100 Received: by fxm24 with SMTP id 24so5832184fxm.17 for ; Wed, 24 Feb 2010 13:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JBGRzl5Hlu7Rk3u3qiLGzzG3dR15E67hZiM3HLa+q4U=; b=giyU01kA9/EmcTtzevdV+DRJgH07xULpfim6c35YdIeHjprisfGkjA8jwF2tX95Y+O hP6JXXDNPISUcuj0UKqIx/aJWkt+4WRJw+i1vLVjgCjhAGLE6IDPRUuELHqD/1DuHsS+ 3nVJH8GWVMacQYa5ecOwGp6xmGM6nZNP0ewsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jb6HBSKJ35HjMAKdLtSeMh/I+Ha6g1c9t6RNm8tX2tQh9+OICM0dpBfXZaoXPpKHqP aX0Bz6+5n0GPHvJgMc3ejrcqVvHPrQjorxUPbMnzc5AB4BfF2+ZHUfBDtuv8FpUWCCKZ yPKi1YhTB6Eho9zyxhSvzy5uQhFsSuwMFVoro= MIME-Version: 1.0 Received: by 10.239.185.84 with SMTP id b20mr26760hbh.91.1267046527024; Wed, 24 Feb 2010 13:22:07 -0800 (PST) In-Reply-To: <87ocje2vtv.fsf@frosties.localdomain> References: <87ocje2vtv.fsf@frosties.localdomain> Date: Wed, 24 Feb 2010 22:22:06 +0100 Message-ID: <4d1b2df21002241322l63b82636hf7465ec05de9d8ed@mail.gmail.com> Subject: Re: [Caml-list] Question about ocaml threads and TLS (on linux) From: Philippe Wang To: Goswin von Brederlow Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml:01 ocaml:01 compiler:01 ocamlopt:01 stub:01 stub:01 ocaml's:01 runtime:01 compiler:01 pointer:01 buf:01 cheers:01 bindings:01 stubs:01 buf:01 Hi, I'm not sure I understand (though I've read the whole text), but maybe this will answer your question: On Linux, OCaml threads (with the native compiler "ocamlopt") are implemented with POSIX threads (in C), so when your OCaml thread runs the C stub, it's the same as if you were running the C stub in some C thread. When you are in a section declared as a blocking section, a collection can be triggered concurrently in another thread and so the heap must not be accessed neither for reading or writing, that's all. Using __thread recent feature should also work if you manage to compile everything correctly. Notably, we use it in some places in ocaml4multicore (a patch to ocaml's runtime library to allow parallel threads). However, I don't know how __thread is handled by the compiler... I mean : it there a pointer for buf in every thread or only in those that use it? I hope my answer isn't useless! Cheers, --=20 Philippe Wang mail@philippewang.info On Wed, Feb 24, 2010 at 10:00 PM, Goswin von Brederlow wrote: > Hi, > > I'm having a little problem for my libfuse-ocaml bindings for the > threaded interface. For those that don't want to read all of the mail my > question is: > > Will every ocaml thread have its own thread-local-storage in the C stubs? > > > I have the following calling sequence: > > User ocaml code =A0 | Fuse C stub =A0 =A0 =A0 =A0 =A0 =A0 =A0| libfuse co= de > ------------------+--------------------------+------------- > Fuse.process fs =A0 > 'process stub' =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| enter_blocking_section() | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| char *buf =3D malloc(size) | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| fuse_session_process() =A0 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0< ops->write(buf+off) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 'write stub' =A0 =A0 =A0 =A0 =A0 =A0= | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| leave_blocking_section() | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| a =3D caml_ba_alloc_dims() | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0< caml_callback(...,a,...) | > my_ref :=3D a =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| enter_blocking_section() > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0< callback done > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 'process stub' =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| free(buf) =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0< leave_blocking_section() | > Fuse.process done | > > > The 'process stub' allocates a buffer and frees it at the end, which is > usualy fine. Except in the case of a write callback where the buffer is > passed back to ocaml as Bigarray. If the Bigarray is copied, like above, > then the ocaml code still has a reference to the data at the point the > 'process stub' wants to free it. > > To solve that problem I need the write callback to signal that the > buffer was passed to ocaml and is now under GC control. The buffer must > not be free()ed by the 'process stub'. The libfuse API does not provide > for this so I have to somehow communicate between 'process stub' and > 'write stub' around the libfuse code. > > > Possible solution: > ------------------ > > __thread char *buf =3D NULL; > > value ocaml_fuse_process(...) { > =A0buf =3D malloc(size); > =A0fuse_session_process() > =A0if (buf !=3D NULL) free(buf); > } > > void write_callback(...) { > =A0a =3D caml_ba_alloc_dims(...); > =A0buf =3D NULL; > } > > > This way ocaml_fuse_process will allocate a new buffer whenever it > doesn't have one and the write_callback will take over the buffer and > give it to the GC. > > > Now my question is: Does that work? Is it safe? Will every ocaml thread > have its own thread-local-storage buf? > > Currently I'm only interested in supporting Linux. If it is safe there > that is enough. > > MfG > =A0 =A0 =A0 =A0Goswin