caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: francois@rouaix.org
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Co-existing with non OCaml threads
Date: Fri, 12 May 2006 13:22:08 +0200	[thread overview]
Message-ID: <1147432929.19900.18.camel@localhost.localdomain> (raw)
In-Reply-To: <f2d6cc680605111729l4d35470ey7e45dcc73822a2b0@mail.gmail.com>

Am Donnerstag, den 11.05.2006, 17:29 -0700 schrieb Francois Rouaix:
> I'm contemplating writing an OCaml interface for a C++ middleware
> library that my company develops and uses internally. Typically this
> middleware will start an event loop on a thread in the background,
> leaving the application responsible for its own threads (and
> potentially using none and having its own code running entirely on
> events within the eventloop thread). 
> How's this likely to be compatible with OCaml use of native threads
> (this is on Linux by the way)?
> The manual section for interfacing with C isn't mentionning threads
> anywhere.
> Should Caml code be restricted to run on threads it has created? Or
> can it run on any threads? 
> How can I synchronize between a thread running C++ code and a thread
> running OCaml code (i.e. both communicating on a message queue)?
> Thanks for any suggestions.

If you compile ocaml with pthread support, the O'Caml threads are real
Linux threads. When using them, be aware of:

- The memory management code is not thread-safe. That means 
  only one thread is allowed to run O'Caml code at any time.
  To ensure this there is the so-called "master lock". You
  can acquire the master lock by calling

  leave_blocking_section()

  and you can release it by

  enter_blocking_section()

  When you call a C function that may block for indefinite time
  one usually releases the lock first, calls the function, and
  then requires it. The stub function looks like

  value foo_stub (...) {
     ...
     enter_blocking_section();
     /* From here: NO ACCESS to any O'Caml memory, not even
      * CAMLparam/CAMLlocal variables!
      */
     ...
     foo();
     ...
     leave_blocking_section();
     /* Normal rules for stub functions apply again */
     ...
  }

  For callbacks from C code you will typically first call 
  leave_blocking_section() and later enter_blocking_section()
  before you return.

- O'Caml must never see threads not created by itself. This 
  means a thread created by your middleware must not run
  O'Caml code. (You get immediately a segfault if you try.)

- Although O'Caml mutexes and condition variables actually
  base on their pthread counterparts, there is no interface
  from the C side. So you better do any synchronization 
  completely in C, i.e. the message queue is written in C
  and uses the normal pthread primitives. The O'Caml stub
  functions accessing this queue need to call
  enter/leave_blocking_section as explained.

Hope this helps. Had to solve a similar problem for a customer.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


  parent reply	other threads:[~2006-05-12 11:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12  0:29 Francois Rouaix
2006-05-12  3:27 ` [Caml-list] " Ted Kremenek
2006-05-12 11:22 ` Gerd Stolpmann [this message]
2006-05-12 16:10   ` Vincenzo Ciancia
2006-05-12 16:30     ` [Caml-list] " Markus Mottl
2006-05-12 17:43   ` [Caml-list] " Ted Kremenek
2006-05-12 18:51     ` Gerd Stolpmann
2006-05-12 19:24       ` Ted Kremenek
2006-05-12 20:44     ` Markus Mottl
2006-05-12 21:00       ` Ted Kremenek
2006-05-13  9:30 ` Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1147432929.19900.18.camel@localhost.localdomain \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=francois@rouaix.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).