From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 88A4EBBAF for ; Sat, 9 Jan 2010 12:33:26 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhICADv4R0tV2gB5mWdsb2JhbACDXpd9AQEBAQEICwoHE6ssjGSBK4IuVgSJJg X-IronPort-AV: E=Sophos;i="4.49,247,1262559600"; d="scan'208";a="53553429" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail4-smtp-sop.national.inria.fr with SMTP; 09 Jan 2010 12:33:26 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 55935B103F7; Sat, 9 Jan 2010 12:33:20 +0100 (CET) Message-ID: <4B486974.7060007@citycable.ch> Date: Sat, 09 Jan 2010 12:33:08 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: David Allsopp Cc: 'caml-list List' Subject: Re: [Caml-list] problem creating .cma library References: <56670.41.177.16.252.1262195331.squirrel@41.177.16.252> <4B3BE288.4030701@citycable.ch> <3EE07409-9559-4B91-BA3E-8787D1378275@inria.fr> <4B47C201.7090201@citycable.ch> <4B47C59C.9080505@starynkevitch.net> <4B47C9BE.4060309@citycable.ch> <001f01ca9101$7ee76850$7cb638f0$@romulus.metastack.com> In-Reply-To: <001f01ca9101$7ee76850$7cb638f0$@romulus.metastack.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 ocaml:01 camlparam:01 camlreturn:01 stubs:01 stubs:01 camlparam:01 pointer:01 ocaml:01 bindings:01 camlreturn:01 optimise:01 camlp:01 -like:01 David Allsopp a =C3=A9crit : > Guillaume Yziquel: > >> So, no allocation of OCaml values (or in place modification, either, I >> guess) implies no need for CAMLparam/CAMLreturn stuff? >=20 > Chapter 18 of the manual in Section 18.5 describes pretty much everythi= ng you need to know about writing safe stubs that work with the garbage c= ollector. =20 Yes. It is all I need to know to write safe stubs. But it does not=20 answer the question above. It does state that you do not need=20 registration of the result value if there's no allocation going on=20 between the moment result get its value and the return statement. But it=20 does not say when you can avoid CAMLparam macros. By the way, here's a question I've been wondering about this section.=20 Rule 3: When I have a Abstract_tag block used to wrap a pointer in the C=20 heap, it seems to me that you can just do it with a Field(v,0)=3D=20 assignment. Do you need Store_field for that? >> I want to understand them so that I can abstract away in some other fi= le >> / .so, some rather usual constructs involving OCaml structures. I thin= k >> it is smarter to take some time doing this, with detailed comments all >> over, than repeating the same mistakes over and over (or worse: >> wondering if you made mistakes) when doing C bindings. >=20 > Having written a few C stubs myself, I'd also highly recommend just fol= lowing the manual and not worrying about what the macros do - if you want= /need to improve allocation performance then you can use the lower-level = interface for allocation (but that still involves CAMLparamn/CAMLreturn).= I usually find that tricks like this (think Obj.magic) mean that when so= mething goes wrong, there's always a niggling thought in the back of your= mind that it's the trick which has broken everything when in fact it's s= omething blindly obvious but you waste hours double-checking the tricks! Yes, but it's also quite a pain not to optimise the binding when you're=20 trying to bind a columnar database that compiles SQL to its own language=20 and tat tries to make the best use of CPU cache. You tend to feel guilty.= .. > In the ideal world, the C written for C stubs would be parsed by a caml= p4-like pre-processor which would automatically insert the expansion of t= hose macros where required. If you have CAMLparamn and CAMLreturn on func= tions which don't strictly need them then you're only creating a few more= local roots than are strictly necessary which isn't likely to hurt that = much... Maybe. I'm not so sure about that... > David All the best, --=20 Guillaume Yziquel http://yziquel.homelinux.org/