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 SAA08233 for caml-redistribution; Wed, 1 Mar 2000 18:06:06 +0100 (MET) 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 QAA18164 for ; Tue, 29 Feb 2000 16:49:35 +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 QAA15665 for ; Tue, 29 Feb 2000 16:49:17 +0100 (MET) Received: from univ-savoie.fr (lama-d134.univ-savoie.fr [193.48.123.134]) by julie.univ-savoie.fr (8.9.3/jtpda-5.3.3) with ESMTP id QAA48252 for ; Tue, 29 Feb 2000 16:49:13 +0100 (CET) Sender: weis Message-ID: <38BBEA7A.BCC0B1E4@univ-savoie.fr> Date: Tue, 29 Feb 2000 16:49:14 +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.13-7mdk i686) X-Accept-Language: fr, en MIME-Version: 1.0 CC: caml-list@inria.fr Subject: GC + thread References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The following extension for Ocaml GC seems to me simple and necessary (I really do need it): It considers only channels dans thread and I will describe it for a mark and swip GC. rule 1: a channel can be marked by the GC in two ways: read or write. rule 2: a channel that is accssible by the GC in the usual way is both marked read and write (usual means in a way no covered by rule 3). rule 3: if a closure if blocked while trying to read from channel R_1, ..., R_n or to write from channel W_1, ..., W_n - the channels R_1,..,R_n are marked as read - the channels W_1,..,W_n are marked as write - the closure will be examined by the GC if and only if one the channel R_i is marked write or one the channel W_i is marked read if the condition is not immidiately true, the examination of the closure is postponed. - if no channel R_i are marked write and no channel W_i are marked read at the end of the mark pass, the closure and the corresponding thread can be safely destroyed (the thread will never wake up). So clearly this require only a modification of the GC of blocked thread and needs to keep to extra bits for channels (this is not a big cost). I would be good to also introduce mono-directional channel (the function create return a pair with an in_channel and an out_channel). In this case the GC ca be optimized to collect more threads in a trivial way (when the GC reaches the in part of a channel it is only marked read and if the GC reaches the out part of a channel it is only marked write). 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 ? -- 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