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 QAA01818 for caml-redistribution; Tue, 3 Nov 1998 16:59:34 +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 KAA26241 for ; Tue, 3 Nov 1998 10:32:54 +0100 (MET) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id KAA05413 for ; Tue, 3 Nov 1998 10:32:53 +0100 (MET) Received: from l-mhs1.lannion.cnet.fr ([161.104.1.59]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id VZR6B4X1; Tue, 3 Nov 1998 10:32:55 +0100 Received: from lsun162 (lsun162.lannion.cnet.fr [161.104.8.27]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WDH4WSP9; Tue, 3 Nov 1998 10:32:55 +0100 From: Pascal Brisset MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13886.52675.191195.689875@lsun162> Date: Tue, 3 Nov 1998 10:32:51 +0100 (MET) To: Thierry Bravier CC: caml-list@inria.fr Subject: Re: problem with ocamlmktop (contd) In-Reply-To: <13881.64982.392952.452261@whynot> References: <3624D5BE.3060@dassault-aviation.fr> <19981015192243.14795@pauillac.inria.fr> <3627228B.20CE@dassault-aviation.fr> <36349D52.1E7B@dassault-aviation.fr> <13881.37437.266875.483207@lsun162> <13881.64982.392952.452261@whynot> X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: weis Pascal Brisset writes: > (3) catching a C++ exception generated by a C++ primitive called > through a Caml callback. Oops, I shouldn't have included the last part... Here is a tentative list of issues regarding exceptions and Caml/C++ interfacing. I hope others will contribute; this is definitely tricky. * g++-2.8.1 seems to link C/C++ reliably, therefore nesting Caml/C++ and C++/Caml calls without exceptions on either side should be safe. * C++ primitive raising a Caml exception: The following code is incorrect because mlraise uses siglongjmp, which does not unwind the C++ stack (obj will not be destroyed): | extern "C" value caml_stub(value) { | Object obj(...); | mlraise(...); | } This might be safe for practical purposes: | extern "C" value caml_stub(value) { | try { /* pure C++ stuff */; } | catch (...) { failwith("Uncaught C++ exception"); } | } but only a C++ expert could tell whether the exception's destructor (if any) will be called... * Callback raising a Caml exception: This is unsafe for the same reason: | extern "C" value caml_stub(value) { | Object obj(...); | callback(...); | } * C++ primitive throwing a C++ exception: We might want to have the interpreter translate all C++ exceptions into Caml exceptions: | Instruct(C_CALL1): | Setup_for_c_call; | try { accu = cprim[*pc](accu); } | catch (...) { | local_roots = initial_local_roots; | failwith("Uncaught C++ exception"); | } | Restore_after_c_call; | ... The local_roots assignment is meant to handle exceptions thrown from within a Begin_roots/End_roots block (i.e. don't let failwith() allocate memory while local_roots points to an obsolete stack frame). Is this enough ? * Caml callback throwing a C++ exception (i.e. trying to embed Caml code in C++ code transparently like in my example): I believe similar changes are required in order to return from interprete() gracefully (catch the C++ exception, handle things like external_raise, callback_depth and local_roots, then re-throw the exception). Has anyone done this ? - Pascal Brisset +33296051928 - - France Telecom CNET DTL/MSV | 2 av Pierre Marzin | F-22307 Lannion -