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 (11:33)
From: Guillaume Yziquel <guillaume.yziquel@c...>
Subject: Re: [Caml-list] problem creating .cma library
David Allsopp a écrit :
> Guillaume Yziquel:
>> 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.  

Yes. It is all I need to know to write safe stubs. But it does not 
answer the question above. It does state that you do not need 
registration of the result value if there's no allocation going on 
between the moment result get its value and the return statement. But it 
does not say when you can avoid CAMLparam macros.

By the way, here's a question I've been wondering about this section. 
Rule 3: When I have a Abstract_tag block used to wrap a pointer in the C 
heap, it seems to me that you can just do it with a Field(v,0)= 
assignment. Do you need Store_field for that?

>> 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!

Yes, but it's also quite a pain not to optimise the binding when you're 
trying to bind a columnar database that compiles SQL to its own language 
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 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...

Maybe. I'm not so sure about that...

> David

All the best,

      Guillaume Yziquel