From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA11440; Wed, 4 Sep 2002 12:15:44 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 MAA11406 for ; Wed, 4 Sep 2002 12:15:43 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g84AFf103867 for ; Wed, 4 Sep 2002 12:15:42 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id TAA24917; Wed, 4 Sep 2002 19:15:23 +0900 (JST) To: markus@oefai.at Cc: caml-list@inria.fr Subject: Re: [Caml-list] Native threads under Debian 3.0r0 In-Reply-To: <20020904094432.GA1375@kiefer.ai.univie.ac.at> References: <20020903230314.GA311@gogol> <20020904094432.GA1375@kiefer.ai.univie.ac.at> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020904191523M.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 04 Sep 2002 19:15:23 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Markus Mottl > > There indeed seems to be something broken about threads (at least native > ones). Things work fine with byte-code and the toplevel, but native > code + native threads don't. I have managed to reproduced this problem > under Linux and Solaris with OCaml 3.06, but also with an older version > (3.04+10 - 2002-04-18) on an Alpha (Digital Unix). This behaviour is normal, and I believe documented. Looking around line 270 in otherlibs/systhreads/posix.c gives the explanation. You cannot switch between caml threads just anywhere, you have to choose a safe place to do that. The way to do that is to raise a flag requesting a thread change, and wait for the code to actually release control. In bytecode "something_to_do" is used, and checked pretty often: at every function call and every loop iteration. However, this would mean too much overhead for native code, so switching is only checked when the GC is called. To make it work even on slowly allocating programs, the young generation is declared "full" every once in a while, but there must still be some allocation for it to happen. So the answer is: a native code thread should be allocating some data, otherwise it cannot be interrupted. The problem does not exist for bytecode. --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG > > $ cat toto.ml > > open Thread > > > > let _ = > > let code1 () = > > let x = ref 0 in > > while true do > > incr x; > > Printf.printf "alpha %d\n" !x; > > flush stdout > > done > > in > > let thread1 = Thread.create code1 () > > in > > while true do > > () > > done > > > > compiled with > > > > $ ocamlopt.opt -thread unix.cmxa threads.cmxa toto.ml -o toto > > > > and run as > > > > $ ./toto > > > > give me something like > > > > alpha 0 > > alpha 1 > > alpha 2 > > alpha 3 > > alpha 4 > > alpha 5 > > alpha 6 > > ... > > > > ? > > > > Instead, the program doesn't output anything, and when I hit Ctrl-C, > > it leaves some processes running, which can only be killed with > > SIGKILL. > > > > The program works when compiled as bytecode. System info : > > > > $ uname -a > > Linux gogol 2.4.18 #1 Thu Aug 22 20:42:28 CEST 2002 i586 unknown > > $ ls -l /lib/libpthread* > > -rw-r--r-- 1 root root 102172 Apr 28 11:57 /lib/libpthread-0.9.so > > > > However, even in bytecode, when I use the Graphics module, some subprocesses > > refuse to die when I interrupt the main program. > > > > Any clues ? Thanks very much. > > -- > > Berke Durak ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners