Browse thread
problem with ocamlmktop -output-obj
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Pascal Brisset <pascal.brisset@c...> |
| Subject: | Re: problem with ocamlmktop (contd) |
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 -