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 GAA27750; Sat, 28 Aug 2004 06:38:37 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 GAA24771 for ; Sat, 28 Aug 2004 06:38:36 +0200 (MET DST) Received: from asmtp-a063f33.pas.sa.earthlink.net (asmtp-a063f33.pas.sa.earthlink.net [207.217.120.149]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i7S4cZJm030307 for ; Sat, 28 Aug 2004 06:38:36 +0200 Received: from 168-103-58-53.tcsn.qwest.net ([168.103.58.53] helo=dylan) by asmtp-a063f33.pas.sa.earthlink.net with asmtp (Exim 4.34) id 1C0uz3-0003Pt-5d for caml-list@inria.fr; Fri, 27 Aug 2004 21:38:33 -0700 Message-ID: <002801c48cb9$216fccf0$0401000a@dylan> From: "David McClain" To: "caml" Subject: [Caml-list] C++ Stack Frames Date: Fri, 27 Aug 2004 21:40:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-ELNK-Trace: 7a0ab3eafc8cf994b22988ad1c62733440683398e744b8a476cbe35d0e83357efdda598319093d3ba2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 168.103.58.53 X-Miltered: at nez-perce with ID 41300C4B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; mcclain:01 dmcclain:01 implying:01 unhandled:01 abort:01 admiration:99 neutralize:01 escapes:01 unhandled:01 cleanup:01 runtime:01 mcclain:01 ocaml:01 ocaml:01 handler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Note, I am not implying that OCaml does the conversion of an unhandled exception to a call to abort(). Rather, I can show you that this happens down in the throw handler in libstdc++. I can produce this error in a pure C++ program without any OCaml around to do anything. What puzzles me, and at the same time, inspires admiration for the OCaml team, is that they somehow manage to neutralize these ascending escapes. Were it not for that, there might be a lot of unhandled cleanup in the OCaml code that gets bypassed. No the correct way to handle this situation is down close to the calls into the throwing C++ code, and not far up the dynamic stack chain. It appears from reading the runtime sources on OCaml that they are doing some signal magic. I just was taken by surprise that this happened in a foreign function call as well. That seems like unnecessary overhead most of the time, but probably keeps dummies from getting burned to badly.... David McClain Senior Corporate Scientist Avisere, Inc. +1.520.390.7738 (USA) david.mcclain@avisere.com ------------------- 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