English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
problem creating .cma library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-01-09 (07:58)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] problem creating .cma library
Guillaume Yziquel:
> Basile STARYNKEVITCH a écrit :
> >>
> >> Why do these functions not follow the usual CAMLparam/CAMLreturn
> >> macro stuff?
> >
> > Because they are written by the Ocaml guys (Damien knows really well
> > the Ocaml garbage collector; he wrote it). And also, because these
> > particular functions do not do any allocation of Ocaml values (either
> > directly or indirectly).
> So, no allocation of OCaml values (or in place modification, either, I
> guess) implies no need for CAMLparam/CAMLreturn stuff?

Chapter 18 of the manual in Section 18.5 describes pretty much everything you need to know about writing safe stubs that work with the garbage collector. 

> > My advice for people coding C code for ocaml is the following:
> >
> > 1. *always* use the CAMLparam/CAMLreturn/... macros.
> >
> > 2. if you dare not using them for some very few functions (because
> > they don't allocate, ...) add a big fat comment with a warning inside.
> >
> > Regards
> I want to understand them so that I can abstract away in some other file
> / .so, some rather usual constructs involving OCaml structures. I think
> 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.

Having written a few C stubs myself, I'd also highly recommend just following 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 something 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 something blindly obvious but you waste hours double-checking the tricks!

In the ideal world, the C written for C stubs would be parsed by a camlp4-like pre-processor which would automatically insert the expansion of those macros where required. If you have CAMLparamn and CAMLreturn on functions 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...