From: John Carr <jfc@MIT.EDU>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: OCaml List <caml-list@inria.fr>
Subject: Re: [Caml-list] POSIX Threads: kill
Date: Sat, 17 May 2003 09:21:52 -0400 [thread overview]
Message-ID: <200305171321.JAA30974@psi-phi.mit.edu> (raw)
In-Reply-To: Your message of "Fri, 16 May 2003 11:54:10 +0200." <20030516115410.A8817@pauillac.inria.fr>
> The problem is that C++ exception handling is based on unwinding stack
> frames one by one till a matching exception handler is found. This
> requires stack frames to adhere strictly to a particular format, and
> be equipped with stack descriptors that the C++ stack unwind mechanism
> understands. But of course the stack frames used ocamlopt-generated
> code do not adhere to this format, and do not come with C++ stack
> descriptors. Hence, if the "systhreads" library was using
> pthread_exit and pthread_cancel, the C/C++ runtime system would try to
> unwind Caml stack frames, and just crash the whole program.
If I recall correctly, on some systems this is an easy problem to
solve because there is little or no runtime overhead in using the
standard stack layout and stack descriptor overhead.
On the other hand, ocaml does not use register windows on SPARC and
fixing that would be a big change. Did somebody determine that the
"flat" model was faster, or was it just easier to implement? SPARC
v9 may change the equation because it was designed to make save and
restore instructions fast, reducing window overflow traps to under
50 cycles.
(I remember trying to mix C++, exceptions, and threads back in 1995.
The combination was so unreliable that I gave up. If a program used
exceptions the exception handlers interfered with thread stack
unwinding and caused core dumps inside the Solaris C++ support library.)
-------------------
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
next prev parent reply other threads:[~2003-05-17 13:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-16 8:24 Christoph Bauer
2003-05-16 9:54 ` Xavier Leroy
2003-05-17 13:21 ` John Carr [this message]
2003-05-20 19:48 ` [Caml-list] register windows Xavier Leroy
2003-05-20 21:26 ` John Carr
2003-05-24 9:56 ` Xavier Leroy
2003-06-02 21:00 ` [Caml-list] POSIX Threads: kill John Max Skaller
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=200305171321.JAA30974@psi-phi.mit.edu \
--to=jfc@mit.edu \
--cc=caml-list@inria.fr \
--cc=xavier.leroy@inria.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;
as well as URLs for NNTP newsgroup(s).