Browse thread
Rewriting the Digest module causes linking errors
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-03-30 (15:57) |
From: | Xavier Leroy <Xavier.Leroy@i...> |
Subject: | Re: [Caml-list] Re: Random segfaults / out of memory |
> So, is it really forbidden to release the global lock in a noalloc function? 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". Hope this helps, - Xavier Leroy