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
------------------------------------------------------------
next prev 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