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 TAA32151 for caml-redistribution@pauillac.inria.fr; Thu, 2 Mar 2000 19:29:53 +0100 (MET) Resent-Message-Id: <200003021829.TAA32151@pauillac.inria.fr> 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 KAA30786 for ; Thu, 2 Mar 2000 10:34:19 +0100 (MET) Received: from julie.univ-savoie.fr (univax.univ-savoie.fr [193.48.120.32]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id KAA27000 for ; Thu, 2 Mar 2000 10:34:02 +0100 (MET) Received: from univ-savoie.fr (bppp2.univ-savoie.fr [193.48.120.21]) by julie.univ-savoie.fr (8.9.3/jtpda-5.3.3) with ESMTP id KAA17930 ; Thu, 2 Mar 2000 10:32:52 +0100 (CET) Sender: raffalli@univ-savoie.fr Message-ID: <38BE34F7.1B4405E8@univ-savoie.fr> Date: Thu, 02 Mar 2000 10:31:35 +0100 From: Christophe Raffalli Organization: Laboratoire de =?iso-8859-1?Q?Math=E9matiques?=, =?iso-8859-1?Q?Universit=E9?= de Savoie X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdkfb i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: Max Skaller CC: caml-list@inria.fr Subject: Re: GC + thread References: <38BBEA7A.BCC0B1E4@univ-savoie.fr> <38BDD0C9.D26E970@in.ot.com.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 2 Mar 2000 19:29:53 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Max Skaller wrote: > > Christophe Raffalli wrote: > > This extension is also necessary (it is easy to have realistic examples > > where the GC would collect much more thread with this extension). > > > > What do you think of that ? > > Why is this necessary? In particular, because in/out channels have > reduced functionality, I have opted to use Unix.file_descr instead: > these are converted to/from in/out channels if necessary. in/out channels are not necessary. As you create the pair, there is no extra functionnality. The point is just to help a GC extended to collect potentialy dead thread: If a thread T is blocked while trying to read from channel A and there is an active thread with a pointer on A, you can not collect the thread T. If a thread T is blocked while trying to read from channel A and there is only active thread with a pointer on the in part of A, you can collect the thread T : no thread will ever be able to write on channel A and T will never wakeup. This situation arises in practice every time you have thread which will only write (or read) on a given channel. Then it is better to let the GC know this. As the actual version of Ocaml can not collect threads, it is clear that in/out channel are useless ... But there are a lot of thread applications (like a virtual machine for any process calculus like the pi-calculus) which really needs a GC collecting thread in the way I described in my previous mail. -- Christophe Raffalli Université de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedex tél: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: Christophe.Raffalli@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI