On 24 Aug 2010, at 15:52, Till Varoquaux wrote:

> On Tue, Aug 24, 2010 at 10:21 AM, Florent Monnier
> <monnier.florent@gmail.com> wrote:
>> Le lundi 23 août 2010 22:24:48, Romain Beauxis a écrit :
>>> Le lundi 23 août 2010 07:09:05, Florent Monnier a écrit :
>>>> an alternative method is to provide a string from ocaml to c then c fills
>>>> this  buffer, then you can save allocations by reusing the same buffer,
>>> 
>>>> see:
>>> This is a good idea but I would be a little bit suspicious about using
>>> "noalloc". Even if it works in your tests, this options is very delicate to
>>> use with the Gc, and may segfault in some cases.
>> 
>> could you develop? which cases?
> 
> IIRC noalloc calls release the ocaml lock. This means that the runtime
> can run at the same time as the c call and the GC migh collect your
> string or move it along. Quick rule if thumb is: you are allocating
> your string so you should not use noalloc.

That's not quite right; "noalloc" calls do not have the OCaml runtime in a functioning state at all since the instructions to set it up are not emitted by ocamlopt.

See [1] for Xavier Leroy's explanation on the matter, which I've quoted below:

> Yes.  Actually, it is forbidden to call any function of the OCaml
> runtime system from a noalloc function.
> 
> Explanation: ocamlopt-generated code caches in registers some global
> variables of importance to the OCaml runtime system, such as the
> current allocation pointer.
> 
> When calling a regular (no-"noalloc") C function from OCaml, these
> global variables are updated with the cached values so that everything
> goes well if the C function allocates, triggers a GC, or releases the
> global lock (enabling a context switch).
> 
> This updating is skipped when the C function has been declared
> "noalloc" -- this is why calls to "noalloc" functions are slightly
> faster.  The downside is that the runtime system is not in a
> functioning state while within a "noalloc" C function, and must
> therefore not be invoked.
> 
> The cost of updating global variables is small, so "noalloc" makes
> sense only for short-running C functions (say, < 100 instructions) like
> those from the math library (sin, cos, etc).  If the C function makes
> significant work (1000 instructions or more), just play it safe and
> don't declare it "noalloc".
> 

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2010/03/2e386c384c04f4a424acc44a1fae3abd.en.html

-anil