Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Pascal Brisset <pascal.brisset@cnet.francetelecom.fr>
To: Thierry Bravier <thierry.bravier@dassault-aviation.fr>
Cc: caml-list@inria.fr
Subject: Re: problem with ocamlmktop (contd)
Date: Tue, 3 Nov 1998 10:32:51 +0100 (MET)	[thread overview]
Message-ID: <13886.52675.191195.689875@lsun162> (raw)
In-Reply-To: <13881.64982.392952.452261@whynot>

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 <pascal.brisset@cnet.francetelecom.fr> +33296051928 -
- France Telecom CNET DTL/MSV | 2 av Pierre Marzin | F-22307 Lannion -




  reply	other threads:[~1998-11-03 15:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-14 16:47 problem with ocamlmktop -output-obj Thierry Bravier
1998-10-15 17:22 ` Xavier Leroy
1998-10-16 10:40   ` Thierry Bravier
1998-10-26 16:03     ` Thierry Bravier
1998-10-30 10:17       ` Pascal Brisset
1998-10-30 17:56         ` problem with ocamlmktop (contd) Pascal Brisset
1998-11-03  9:32           ` Pascal Brisset [this message]
1998-11-04 17:56           ` Thierry Bravier
1998-11-04 16:12   ` problem with ocamlmktop -output-obj luther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13886.52675.191195.689875@lsun162 \
    --to=pascal.brisset@cnet.francetelecom.fr \
    --cc=caml-list@inria.fr \
    --cc=thierry.bravier@dassault-aviation.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox