From: Mathieu Bouchard <matju@...>
Date: 2003-08-06T08:00:27+09:00
Subject: Re: exceptions and such


On Sun, 27 Jul 2003, Yukihiro Matsumoto wrote:

> Ruby is originally designed as an application after all.  There are
> some problems embedding it.  The new API should be prepared and
> designed separation of library stuff and application stuff in mind.

Are you actively working on Ruby 2.0 now? How different will the new API
be? What kind of compatibility can be expected?

> |1. any way to call c++ destructors of stack-allocated objects in
> |conjunction with rb_raise/longjmp/etc ? Maybe that's something not
> |possible (as in: not defined by the C++ standard) ?
> I want to know if there's a way.  Only workaround I can think of is
> wrap every ruby callback with rb_protect().

I don't know rb_protect(). It's not in README.EXT, as for many other
useful functions. I don't know what's a more complete and up-to-date
documentation for that.

By googling about it, I found how to use it.

By the way: I found that throw/catch in C++ seems quite slow compared to
raw setjmp/longjmp. I don't know how it manages to be slow like that.
However it's not too significant because that will be seldom used in
comparison to "try", which is very fast. Plus it's the only automatic way
of destroying local C++ objects; I don't have (m)any of those, but that's
only now... I may have more in the future. So it's a good investment.

> |eval.c has a global variable called "prot_tag" that has to do with that,
> |but it's static, so I couldn't implement those two macros myself, because
> |I cannot intercede in the exception-handler-chain without that...
> Not now.  Planned.

When will this happen? Ruby 2.0 ?

> |3. If I use Ruby and pthreads in the same program, and from ruby i
> call |functions in another library that starts threads, but those
> threads aren't |supposed to do anything with the ruby stuff directly,
> is there anything I |need to do for those to work properly? like, mask
> and restore any |signal-handlers?
> No signal handler runs Ruby code directly, so that it should be safe.

No, I mean other kinds of interference. Would signals sent to the 2nd
process still trigger SignalExceptions in the 1st process?

rb_atomic_t trap_immediate is a global variable, and thus shared between
pthread processes, am I right? and so, if signal handlers are shared too,
then a signal handler in thread 2 can appear to the ruby interpreter of
thread 1 as if the signal was triggered on thread 1 ?

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju