From: matz@... (Yukihiro Matsumoto)
Date: 2003-07-27T19:43:33+09:00
Subject: Re: exceptions and such


In message "exceptions and such"
    on 03/07/27, Mathieu Bouchard <matju@sympatico.ca> writes:

|a few questions, possibly difficult to answer:

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.

|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().

|2. is there any way i could have something like rb_ensure but without
|meandering roundabouts ? I mean it's not like I could do things as easily
|as:
|
|TRY { ... } ENSURE { ... }
|
|where TRY and ENSURE are macros that work with Ruby's exception system
|through struct jmp_buf and setjmp() and longjmp().
|
|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.

|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.

|4. What are the signal labels that Ruby uses, and thus may interact badly
|with other libraries that use them? SIGVTALARM, and then? If there is such
|a conflict, what should I do?

Ruby installs signal handlers for SIGINT, SIGHUP, SIGQUIT, SIGALRM,
SIGUSR1, SIGUSR2, SIGBUS, SIGSEGV, and SIGPIPE.

							matz.