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 KAA04829 for caml-redistribution; Mon, 1 Sep 1997 10:30:03 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA24017 for ; Fri, 29 Aug 1997 20:01:27 +0200 (MET DST) Received: from rs1.hrz.th-darmstadt.de (rs1.hrz.th-darmstadt.de [130.83.22.60]) by nez-perce.inria.fr (8.8.7/8.8.5) with SMTP id UAA10955; Fri, 29 Aug 1997 20:01:24 +0200 (MET DST) Received: from crunch (crunch.ikp.physik.th-darmstadt.de [130.83.24.4]) by rs1.hrz.th-darmstadt.de (8.6.12/8.6.12.0ms) with SMTP id UAA26523; Fri, 29 Aug 1997 20:02:28 +0200 Received: by crunch (AIX 3.2/UCB 5.64/Client-1.5/HRZ-THD) id AA05339; Fri, 29 Aug 1997 20:01:22 +0200 Date: Fri, 29 Aug 1997 20:01:22 +0200 Message-Id: <9708291801.AA05339@crunch> From: Thorsten Ohl To: caml-list@inria.fr Cc: Xavier Leroy Subject: Re: Thread library for ocamlopt? In-Reply-To: <199708281130.NAA25330@pauillac.inria.fr> References: <199708270907.SAA11454@nsb.is.titech.ac.jp> <199708281130.NAA25330@pauillac.inria.fr> Sender: weis Xavier Leroy writes: > 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. This is good news and I'm looking forward to it! > * 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. Couldn't the implementation on the latter three OSs emulate the semantics (without the performance benefit, of course) with the old threads? Then programs would remain portable and users of multiprocessor machines running the former three OSs could start chasing around the FORTRAN crowd :-). > * 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. By your high standards it will be considered a nasty hack, but what will prevent us users from adding spurious allocation points, if the scheduling turns out to be too rough in a practical case? Cheers, -Thorsten -- Thorsten Ohl, Physics Department, TH Darmstadt --- PGP: AF 38 FF CE 03 8A 2E A7 http://crunch.ikp.physik.th-darmstadt.de/~ohl/ -------- 8F 2A C1 86 8C 06 32 6B