[#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: testunit, exit status and at_exit

From: "Nathaniel Talbott" <nathaniel@...>
Date: 2003-07-21 19:51:07 UTC
List: ruby-core #1267
Yukihiro Matsumoto [mailto:matz@ruby-lang.org] wrote:

> In message "Re: testunit, exit status and at_exit"
>     on 03/07/21, "Nathaniel Talbott" <nathaniel@talbott.ws> writes:
> 
> |I may get it merged before the 1.8 release; if not, expect it for sure 
> |in 1.8.1.
> 
> OK.  But you need to help me to clarify the problem.  What if 
> there's multiple END proc that calls "exit"?  Can I choose 
> arbitrary one?

I was wondering if that would be a problem. For my situation, either of the
following would work:

  1. The last exit status that is set wins. So if there are multiple END
procs, and they all set the exit status (by calling #exit), the last one
registered wins (END procs are called in the order they are defined,
correct?)
  2. Calling #exit in an END proc does nothing, but calling #exit!
immediately terminates with the given status (skipping any remaining END
procs).

From my perspective either one of these will work; others may have a
preference and/or additional ideas.

Thanks,


Nathaniel

<:((><


In This Thread