Hello
Here is the latest Caml Weekly News, for the week of March 30 to April 06, 2010.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/cffb366ebd4fd448/96741ec49e9bb2b2
Deep in this thread, Goswin von Brederlow said:
I finaly tracked down the issue with the help of Erkki Seppala.
First problem:
I had the function declared as "noalloc" but used CAMLparam2() in
it. That seems to cause random segfaults. I don't understand why but if
I remove the "noalloc" then it works.
Second problem:
When I remove the CAMLparam2() the finalizer is called too early:
CAMLprim value md5_update_bigarray(value context, value vb)
{
//CAMLparam2(context, vb);
struct helper *helper = (struct helper*)Data_custom_val(context);
struct MD5Context *ctx = helper->ctx;
fprintf(stderr, "update_bigarray: helper = %p, ctx = %p\n", helper, ctx);
struct caml_ba_array * b = Caml_ba_array_val(vb);
unsigned char *data = b->data;
uintnat len = caml_ba_byte_size(b);
caml_enter_blocking_section();
caml_MD5Update(ctx, data, len);
caml_leave_blocking_section();
//CAMLreturn(Val_unit);
return Val_unit;
}
let rec loop () =
Mutex.lock mutex;
if !num = 0
then Mutex.unlock mutex
else begin
decr num;
Mutex.unlock mutex;
let context = context () in
let () = update_bigarray context buf
in
loop ()
end
in
loop ()
This sometimes results in the following code flow:
context () <- allocates memory
update_bigarray context buf
caml_enter_blocking_section();
THREAD SWITCH
GC runs
context is finalized <- frees memory
THREAD SWITCH BACK
caml_MD5Update(ctx, data, len); <- writes to ctx which is freeed
Looks like ocamlopt really is so smart that is sees that context is
never used after the call to update_bigarray and removes it from the
root set before calling update_bigarray. It assumes the update_bigarray
will hold all its arguments alive itself, which is a valid assumption.
This is a tricky situation. The md5_update_bigarray() on its own is a
"noalloc" function. But due to the caml_enter_blocking_section() another
thread can alloc and trigger a GC run in parallel. So I guess that makes
the function actually not "noalloc".
David Baelde then asked:Thanks for reporting about your experience! This made me suspect noalloc in a bug of mine, and indeed removing a bunch of noalloc did the trick. Now I'd like to understand. Unlike in your example, global roots were registered for the bigarrays in "my" functions. This should avoid that they are freed when the global lock is released. Still, noalloc seems wrong with those functions. I'm not sure yet which function is problematic in my case, but they all follow the same scheme, see for example http://savonet.rastageeks.org/browser/trunk/liquidsoap/src/stream/rgb_c.c#L563. So, is it really forbidden to release the global lock in a noalloc function?To which Xavier Leroy replied:
> 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".Markus Mottl then said:
It may not always be clear to developers whether a function provided by the OCaml API is safe. E.g. calling Val_int is fine (at least now and for the foreseeable future), but caml_copy_string is not. I agree that people should generally avoid noalloc. The speed difference is clearly negligible in almost all practical cases. Note, too, that sometimes people forget that they had declared a previously safe function as "noalloc", but later change the C-code in ways that breaks this property. The tiny extra performance may not be worth that risk.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/93a1abe6b2b091eb#
Jake Donham announced:I am happy to announce version 0.3 of orpc, a tool for generating RPC bindings from OCaml signatures. Orpc can generate ONC RPC stubs for use with Ocamlnet (in place of ocamlrpcgen), and it can also generate RPC over HTTP stubs for use with ocamljs. You can use most OCaml types in interfaces, as well as exceptions and labelled/optional arguments. Changes since version 0.2 include * a way to use types defined outside the interface file, so you can use a type in more than one interface * support for polymorphic variants * a way to specify "abstract" interfaces that can be instantiated for synchronous, asynchronous, and Lwt clients and servers * bug fixes Development of orpc has moved from Google Code to Github; see * project page: http://github.com/jaked/orpc * documentation: http://jaked.github.com/orpc * downloads: http://github.com/jaked/orpc/downloads I hope you find this work useful. Let me know what you think.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/173d31821deaaa9b#
John Whitington announced:I’ve written a version of Ocaml’s Graphics module which outputs PDF directly, using the CamlPDF library - its only dependency. It’s based on the approach of Pierre Weis’ GraphPS program. It has the same API as Ocaml’s module - just have your build process find the GraphPDF files before it finds the system ones - the vast majority of programs shouldn’t need altering. http://www.coherentpdf.com/graphpdf-1.0.tar.bz2
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/1f85a654ed29f4d7#
Grant Olson announced:Chess III Arena is a chess game that uses Quake 3 characters as the chess pieces. Version 0.8 includes many improvements over the last version. I'll only go into two major improvements here: 1) The distribution now includes everything you need to play. Previous versions required access to an official copy of Quake 3 to get the character art. This version now includes gpl licensed character art courtesy of the openArena project. 2) C3A can now be used as a graphical front-end for gnuchess, allowing you to play a computer opponent. More information, source downloads, and a binary Windows download can be found here: http://www.grant-olson.net/ocaml/chess-iii-arena
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/3566a5f25ba5af36#
Daniel Bünzli announced:It is my pleasure to announce that Xavier Leroy and Didier Rémy's course on Unix system programming in Objective Caml is now available in english at this address : http://ocamlunix.forge.ocamlcore.org/ If you had a look at the individual publications of the chapters announced on the project feed you may want to have a look again: some parts of the text were improved and a few translation errors were corrected in the final version. The translation was made by : * Eric Cooper * Eliot Handelman * Priya Hattiangdi * Thad Meyer * Prashanth Mundkur * Richard Paradies * Till Varoquaux * Mark Wong-VanHaren * Daniel C. Bünzli And the resulting text was proofread by : * David Allsopp * Erik de Castro Lopo * John Clements * Anil Madhavapeddy * Prashanth Mundkur. A big thank to all of them for the time they provided for the project. A special mention goes to Prashanth Mundkur who was very supportive and responsive all along. He not only proofread more than one chapter but also provided fixes and improvements for every part of the document. Thanks also to all the people working on ocamlcore.org for the hosting resources.
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/.
The course on Unix System programming in OCaml is translated:
http://forge.ocamlcore.org/forum/forum.php?forum_id=573
Xavierbot 0.9:
http://rwmj.wordpress.com/2010/04/04/xavierbot-0-9/
ocaml bindings for picosat:
https://mancoosi.org/~abate/ocaml-bindings-picosat
What is the defacto OCaml build tool?:
http://www.wisdomandwonder.com/link/4665/what-is-the-defacto-ocaml-build-tool
What is the defacto OCaml unit testing tool?:
http://www.wisdomandwonder.com/link/4660/what-is-the-defacto-ocaml-unit-testing-tool
GraphPDF: A PDF Version of Ocaml’s Graphics Module:
http://coherentpdf.com/blog/?p=45
orpc 0.3:
http://ambassadortothecomputers.blogspot.com/2010/04/orpc-03.html
Tip: find out when filesystems get full with virt-df (working version!):
http://rwmj.wordpress.com/2010/04/02/tip-find-out-when-filesystems-get-full-with-virt-df-working-version/
Pourquoi je quitte l'expérience démocratique:
http://bentobako.org/david/blog/index.php?post/2010/04/01/Pourquoi-je-quitte-l-exp%C3%A9rience-d%C3%A9mocratique
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.