From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 13FC0BB84 for ; Fri, 12 May 2006 05:27:41 +0200 (CEST) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4C3Rddn029325 for ; Fri, 12 May 2006 05:27:40 +0200 Received: from [171.64.72.236] (kremenek-macbook.Stanford.EDU [171.64.72.236]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k4C3Rbqe005815 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 11 May 2006 20:27:38 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <862519A3-A7B0-4BAC-B688-F01C2B814377@cs.stanford.edu> Cc: caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Ted Kremenek Subject: Re: [Caml-list] Co-existing with non OCaml threads Date: Thu, 11 May 2006 20:27:36 -0700 To: francois@rouaix.org X-Mailer: Apple Mail (2.749.3) X-Miltered: at concorde with ID 446400AB.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 ocaml:01 threads:01 garbage:01 garbage:01 parallelism:01 abstraction:01 run-time:01 run-time:01 interfacing:01 --f:01 beginner's:01 beginners:01 bug:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 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