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 OAA13824; Mon, 18 Aug 2003 14:40:38 +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 OAA14278 for ; Mon, 18 Aug 2003 14:40:37 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h7ICeYf03540; Mon, 18 Aug 2003 14:40:35 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA08983; Mon, 18 Aug 2003 14:40:34 +0200 (MET DST) Date: Mon, 18 Aug 2003 14:40:34 +0200 From: Xavier Leroy To: Oleg Trott Cc: caml-list@inria.fr Subject: Re: [Caml-list] Type Safety and Interruptions Message-ID: <20030818144034.A15322@pauillac.inria.fr> References: <200308130010.40500.oleg_trott@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200308130010.40500.oleg_trott@columbia.edu>; from oleg_trott@columbia.edu on Wed, Aug 13, 2003 at 12:10:40AM -0400 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 modifies:01 unbounded:01 asynchronous:01 inconsistent:01 caml:01 blocking:01 toplevel:01 partially:02 heap:03 explicitly:03 suppose:03 argument:03 fortran:03 let:04 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Are there any guarantees about type safety even when program execution is > interrupted? Yes. Signals are not processed in a completely asynchronous manner. Rather, they are recorded and processed later when the program reaches a safe program point, e.g. not in the middle of an allocation, an initialization, nor a GC. > As a simple example, suppose f is a function that modifies its argument > (array) frequently, x is some value, and I type in the toplevel: > > > # (* ..... *) > # let a = Array.make 100000 x;; > # f a;; > Interrupted. > > and interrupt it before f finishes. Is it at all possible for array "a" to > be in some odd state when its `value' is inconsistent with its type? No, this cannot happen. The array may be partially modified (depending on what f did before being interrupted), but it will always hold valid integers. > What if "f" also contains calls to foreign (C/FORTRAN) functions? Same thing. By default, the signals are delayed till the foreign function returns and the Caml program hits a safe point. Some foreign functions can explicitly declare a "blocking section" where they are going to block for an unbounded amount of time, and within this section signals will be processed immediately. However, it is part of the "blocking section" contract that the C function must not touch the Caml heap as long as it is within the blocking section, so again heap corruption cannot occur. Hope this helps, - Xavier Leroy ------------------- 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