[#11073] segfault printing instruction sequence for iterator — <noreply@...>
Bugs item #10527, was opened at 2007-05-02 14:42
Hi,
On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:
Hi,
Hi,
This seems to make valgrind much happier.
On Thu, May 17, 2007 at 11:14:35PM +0900, Paul Brannan wrote:
Hi,
Now 'a' shows up twice in the local table:
Hi,
[#11082] Understanding code: Kernel#require and blocks. — Hugh Sasse <hgs@...>
I'm trying to debug a Rails application which complains about an
On 5/4/07, Hugh Sasse <hgs@dmu.ac.uk> wrote:
On Fri, 4 May 2007, George wrote:
On Fri, May 04, 2007 at 06:18:19PM +0900, Hugh Sasse wrote:
[#11108] pattern for implementation-private constants? — David Flanagan <david@...>
Hi,
I believe there isn't a way, but I don't think it's really necessary. Just
[#11127] Bugs that can be closed — "Jano Svitok" <jan.svitok@...>
I propose closing these bugs as invalid:
[#11145] Rational comparison to 0 fails when denominator is != 1 — <noreply@...>
Bugs item #10739, was opened at 2007-05-10 22:06
Hi,
[#11169] Allow back reference with nest level in Oniguruma for Ruby again — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <wonado@...>
Remark: I posted this text in comp.lang.ruby first, but Matz told me,
Does it make sense or is it required to write this as a RCR?
[#11176] FileUtils.rm_rf misfeature? — johan556@...
Hi!
[#11210] Pathname ascend and descend inclusive parameter — TRANS <transfire@...>
I would like to suggest that Pathname#ascend and Pathname#descend
[#11234] Planning to release 1.8.6 errata — Urabe Shyouhei <shyouhei@...>
Hi all.
On 25/05/07, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#11252] Init_stack and ruby_init_stack fail to reinit stack (threads problem?) — <noreply@...>
Bugs item #11134, was opened at 2007-05-25 12:14
Hi,
Nobuyoshi Nakada wrote:
[#11255] ruby_1_8_6 build problem (make install-doc) — johan556@...
Hi!
[#11271] providing better support through rubyforge tracker categories — Ryan Davis <ryand-ruby@...>
I'm going to make more categories for the trackers (bugs and patches)
[#11367] BUG: next in lambda: 1.8.6 differs from 1.8.4 and 1.9.0 — David Flanagan <david@...>
A toplevel next statement in a lambda does not return a value in 1.8.6,
[#11368] $2000 USD Reward for help fixing Segmentation Fault in GC — Brent Roman <brent@...>
Hi Brent,
Re: [ ruby-Bugs-11134 ] Init_stack and ruby_init_stack fail to reinitstack(threads problem?)
Nobuyoshi Nakada wrote:
>
> It does solve nothing.
>
> The point of this problem is that ruby interpreter is not
> thread-safe as a library, so that you must not call it in
> native-threads other than the native-thread on which ruby
> itself is running. Instead, you have to send any requests to
> the native-thread and process them in it.
But like I said, I'm not using it in a non-thread safe way.
Only a single ruby thread keeps running ruby code at a time.
This should be equivalent to having a global lock and running
eval("sth") each time.
Whether the thread_id for it is 0, 1, 2, etc. should not be relevant.
Or is there anything in the ruby code that makes this impossible? It
seems only the GC is constrained by needing info about the stack. But
resetting the stack on each iteration should (mostly) address this.
There's still the rare possibility of some temporary VALUEs on the stack
of the main thread being collected when the new thread with the new
stack beginning runs, but this should be rather rare (I can only think
this can happen if an extension invokes a new thread which in turn calls
some other extension).
Any static or global variables should be fine by being invoked in
different threads.
> (not sure what its
>> purpose is, either -- seems like if you are reading
>> getrlimit values you should use them as is).
>
> To try to catch stack overflow.
>
Still don't follow. Shouldn't the arbitrary / 5 already leave enough
headroom for this? Why the need for the clamp?
>
> It does know about the native-threads which are created in
> ruby. Therefore, you can't store VALUEs on the stacks of other
> threads.
>
Ouch. This sounds much worse than 1.8. How do any C extensions work at
all on a ruby thread other than the main ruby thread?
If I read this correctly, doing something as simple as:
VALUE c;
in any extension will just make the extension not work at all on other
threads. This seems to break, well..., everything.
Or VALUE would need to become a C++ class, with proper
registering/unregistering with the GC then.
> [patch attached...]
What's this? This is not my patch (have not sent it yet -- or written
it, for that matter).
--
Gonzalo Garramu
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy