From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA23526 for caml-redistribution; Fri, 29 Aug 1997 19:34:01 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA25335 for ; Thu, 28 Aug 1997 13:31:11 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id NAA29944; Thu, 28 Aug 1997 13:30:56 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA25330; Thu, 28 Aug 1997 13:30:57 +0200 (MET DST) From: Xavier Leroy Message-Id: <199708281130.NAA25330@pauillac.inria.fr> Subject: Re: Thread library for ocamlopt? In-Reply-To: <199708270907.SAA11454@nsb.is.titech.ac.jp> from Ken Wakita at "Aug 27, 97 06:07:09 pm" To: Ken.Wakita@mail.is.titech.ac.jp (Ken Wakita) Date: Thu, 28 Aug 1997 13:30:56 +0200 (MET DST) Cc: caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > Is there a plan to include the Thread module in the native compiler > framework? Or is there a work done with native concurrent ocaml? The existing thread library works by context-switching at the level of the bytecode interpreter. This makes it highly portable to most Unix systems, but of course the technique does not extend to the native-code compiler. To support native code, the thread library must be built on top of "real" OS threads, e.g. Posix 1003.1c threads or Win32 threads. We have such an implementation of Caml threads for Win32 (bytecode only). Some work is in progress to extend it to Posix threads and to the native-code compiler. The two main drawbacks are: * Available only on Unix systems that provide fully conformant Posix 1003.1c threads, e.g. Solaris 2.5, Digital Unix 4.0, or Linux with LinuxThreads, but not HPUX, SunOS, nor earlier versions of Digital Unix, for instance. * Preemption of long-running threads can only occur at allocation points (for reasons relevant to both the garbage collector and the handling of signals in ocamlopt), which can result in a relatively rough scheduling for compute-bound threads. - Xavier Leroy