[#1207] warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...>

This message was posted to ruby-talk, but I didn't get responce from

22 messages 2003/07/01
[#1208] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/01

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1209] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/02

ts wrote:

[#1210] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/02

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1211] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1212] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1213] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1214] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1215] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1237] FTP.new with block — Gavin Sinclair <gsinclair@...>

Hi,

22 messages 2003/07/19
[#1238] Re: [Patch] FTP.new with block — ts <decoux@...> 2003/07/19

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

[#1240] Re: [Patch] FTP.new with block — Mathieu Bouchard <matju@...> 2003/07/19

[#1297] Fix for Bug 1058 — Markus Walser <walser@...>

Hi,

16 messages 2003/07/25

Re: exceptions and such

From: matz@... (Yukihiro Matsumoto)
Date: 2003-07-27 10:43:33 UTC
List: ruby-core #1316
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.

In This Thread