[#2367] Standard libraries — Dave Thomas <dave@...>

From ruby-dev summary:

60 messages 2004/02/11

[#2397] PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library — Gavin Sinclair <gsinclair@...>

Index: cgi-lib.rb

15 messages 2004/02/12

[#2465] PATCH: OpenStruct#initialize to yield self — Gavin Sinclair <gsinclair@...>

This is a common approach I use to object initialization; I don't know

24 messages 2004/02/19

Re: rehash segfault

From: Joel VanderWerf <vjoel@...>
Date: 2004-02-24 18:51:17 UTC
List: ruby-core #2497
Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "rehash segfault"
>     on 04/02/25, Nathaniel Talbott <nathaniel@talbott.ws> writes:
> 
> |I don't have a lot of information on this bug at this point, but 
> |figured I'd throw out what I do have, and see if it's enough to jog 
> |someone's brain. I'll of course continue to gather more information as 
> |I'm able and present it here.
> |
> |I have code that looks like this in my application:
> |
> |   @cache = Set::new
> |   def @cache.rehash
> |     @hash.rehash
> |   end
> 
> Ruby hashes are not completely thread-safe.  I knew the problem
> existed, but I couldn't fix it without significant slow-down.
> Can you isolate cache access for each threads?

Does this mean that some of the Hash methods are not atomic w.r.t. the 
thread scheduler? Which ones? It's understandable that if h[x] invokes 
the default proc, you lose atomicity. Are there any surprising cases?

In This Thread