From: Ted Kremenek <kremenek@cs.stanford.edu>
To: francois@rouaix.org
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Co-existing with non OCaml threads
Date: Thu, 11 May 2006 20:27:36 -0700 [thread overview]
Message-ID: <862519A3-A7B0-4BAC-B688-F01C2B814377@cs.stanford.edu> (raw)
In-Reply-To: <f2d6cc680605111729l4d35470ey7e45dcc73822a2b0@mail.gmail.com>
Hi Francois,
From my understanding of OCaml threads, they are non-preemptive user-
level threads that run within a single kernel thread. Further, OCaml
does not employ a concurrent garbage collector; essentially the whole
program stops (including all OCaml threads) when the garbage
collector runs. OCaml threads do not provide any additional actual
parallelism (they are not preemptive like kernel threads), but like
all user-level threads they provide an abstraction of parallel
threads as a programming idiom. I am not certain if in the
implementation of OCaml threads that one thread automatically yields
to another when it calls a blocking operation like an I/O operation
(like the user-level thread implementation for C described in the
Capriccio paper that appeared in SOSP a few years ago), but I doubt it.
You might be able to run the OCaml run-time (I am talking about
native code) within a program that employs multiple kernel threads as
long as ALL the OCaml code runs in one designated thread, but the run-
time was not designed to be executed within multiple kernel threads.
Of course I could be completely wrong about this, but this was my
interpretation from the documentation, previous emails on this list,
and from my brief circumspection of the code from the OCaml run-time.
Ted
On May 11, 2006, at 5:29 PM, Francois Rouaix wrote:
> 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.
> --f
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
next prev parent reply other threads:[~2006-05-12 3:27 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 ` Ted Kremenek [this message]
2006-05-12 11:22 ` [Caml-list] " Gerd Stolpmann
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=862519A3-A7B0-4BAC-B688-F01C2B814377@cs.stanford.edu \
--to=kremenek@cs.stanford.edu \
--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