[#2320] Problems in mathn, rational, complex, matrix — Gavin Sinclair <gsinclair@...>
I received a message from Richard Graham mentioning a problem in the
5 messages
2004/02/01
[#2346] Patch for socket.c: control reverse lookup for every instance — Thomas Uehlinger <uehli@...>
Hi all
4 messages
2004/02/05
[#2357] Use the BasicSocket#do_not_reverse_lookup flag in Webrick — Thomas Uehlinger <uehli@...>
Hi
5 messages
2004/02/07
[#2367] Standard libraries — Dave Thomas <dave@...>
From ruby-dev summary:
60 messages
2004/02/11
[#2373] Re: Standard libraries
— matz@... (Yukihiro Matsumoto)
2004/02/11
Hi,
[#2429] Re: Standard libraries
— "NAKAMURA, Hiroshi" <nahi@...>
2004/02/13
Hi,
[#2432] Re: Standard libraries
— "Sean E. Russell" <ser@...>
2004/02/13
By the way, this issue is about a matter of taste, so the debate is somewhat
[#2437] Re: Standard libraries
— "J.Herre" <jlst@...>
2004/02/13
[#2386] Re: Standard libraries
— "NAKAMURA, Hiroshi" <nahi@...>
2004/02/12
Hi,
[#2392] Re: Standard libraries
— Mauricio Fern疣dez <batsman.geo@...>
2004/02/12
On Thu, Feb 12, 2004 at 02:58:22PM +0900, NAKAMURA, Hiroshi wrote:
[#2393] Re: Standard libraries
— Gavin Sinclair <gsinclair@...>
2004/02/12
On Thursday, February 12, 2004, 8:18:32 PM, Mauricio wrote:
[#2401] Re: Standard libraries
— "Sean E. Russell" <ser@...>
2004/02/12
On Thursday 12 February 2004 04:37, Gavin Sinclair wrote:
[#2405] Re: Standard libraries
— Gavin Sinclair <gsinclair@...>
2004/02/12
On Friday, February 13, 2004, 12:44:15 AM, Sean wrote:
[#2410] Re: Standard libraries
— "Sean E. Russell" <ser@...>
2004/02/12
(Dave Thomas: there's a question for you in the second paragraph; if you're
[#2397] PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library — Gavin Sinclair <gsinclair@...>
Index: cgi-lib.rb
15 messages
2004/02/12
[#2398] Re: PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library
— E F van de Laar <emiel@...>
2004/02/12
* Gavin Sinclair (gsinclair@soyabean.com.au) wrote:
[#2399] Re: PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library
— Gavin Sinclair <gsinclair@...>
2004/02/12
On Thursday, February 12, 2004, 11:39:37 PM, E wrote:
[#2402] Re: PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library
— matz@... (Yukihiro Matsumoto)
2004/02/12
Hi,
[#2404] Re: PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library
— "NAKAMURA, Hiroshi" <nahi@...>
2004/02/12
Hi,
[#2422] Re: [ruby-cvs] ruby: * lib/ftools.rb: documented — "U.Nakamura" <usa@...>
Hello,
6 messages
2004/02/13
[#2449] make install not getting through rdoc phase — "David A. Black" <dblack@...>
Hi --
7 messages
2004/02/16
[#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
[#2468] Change to #new (was OpenStruct#initialize to yield self)
— Dave Thomas <dave@...>
2004/02/19
[#2469] Re: Change to #new (was OpenStruct#initialize to yield self)
— Austin Ziegler <austin@...>
2004/02/19
On Fri, 20 Feb 2004 02:42:00 +0900, Dave Thomas wrote:
[#2470] Re: Change to #new (was OpenStruct#initialize to yield self)
— Carlos <angus@...>
2004/02/19
> > As more general suggestion. Could 'new' yield the new object is a block
[#2471] Re: Change to #new (was OpenStruct#initialize to yield self)
— Austin Ziegler <austin@...>
2004/02/20
On Fri, 20 Feb 2004 08:24:31 +0900, Carlos wrote:
[#2472] Re: Change to #new (was OpenStruct#initialize to yield self)
— Dave Thomas <dave@...>
2004/02/20
[#2476] Re: PATCH: OpenStruct#initialize to yield self
— matz@... (Yukihiro Matsumoto)
2004/02/20
Hi,
[#2482] Re: PATCH: OpenStruct#initialize to yield self
— Joel VanderWerf <vjoel@...>
2004/02/21
Yukihiro Matsumoto wrote:
[#2485] Re: PATCH: OpenStruct#initialize to yield self
— "J.Herre" <jlst@...>
2004/02/21
On Feb 20, 2004, at 4:33 PM, Joel VanderWerf wrote:
[#2494] rehash segfault — Nathaniel Talbott <nathaniel@...>
I don't have a lot of information on this bug at this point, but
10 messages
2004/02/24
[#2495] Re: rehash segfault
— matz@... (Yukihiro Matsumoto)
2004/02/24
Hi,
[#2498] Re: rehash segfault
— Eivind Eklund <eivind@...>
2004/02/24
On Wed, Feb 25, 2004 at 03:30:54AM +0900, Yukihiro Matsumoto wrote:
[#2504] foldl and foldr — "Sean E. Russell" <ser@...>
Sorry if I'm opening old wounds; I have a hard time believing that nobody has
6 messages
2004/02/25
Re: rehash segfault
From:
Eivind Eklund <eivind@...>
Date:
2004-02-25 11:59:56 UTC
List:
ruby-core #2501
On Wed, Feb 25, 2004 at 05:44:30PM +0900, Yukihiro Matsumoto wrote:
> In message "Re: rehash segfault"
> on 04/02/25, Eivind Eklund <eivind@FreeBSD.org> writes:
>
> |> Ruby hashes are not completely thread-safe. I knew the problem
> |> existed, but I couldn't fix it without significant slow-down.
> |
> |What is the exact problem that makes it hard to fix without slowdown?
>
> Hash calls back a few Ruby methods, e.g. "hash", "eql?", etc, during
> which context switch may happen. To avoid this, the easiest way is to
> prepare mutex for each hash and protect every hash operation, that, I
> think, cause significant slow-down.
This is a fun problem! :-)
As far as I can tell, the only "atomic"[1] ops available in the
ruby source code are the ATOMIC_ code in rubysig.h. Is this correct?
I *think* I can do an implementation based on sequencing all rehashes,
turning rehash into an incremental operation where elements are moved
from the old to the new map, tracking active/quiscent maps, and having a
hash lookup during a rehash look into both the old and the new table.
This would give the following extra cost compared to a non-threadsafe
variant:
For read and write:
1 ATOMIC_INC for starting
1 ATOMIC_DEC for ending
One extra test of a pointer variable
During rehashing:
Partial extra scan (need to both scan the present table and the
table being buit)
One extra ATOMIC_INC
One extra ATOMIC_DEC
For rehashing:
One mutex test (no parallell rehashing allowed)
The extra memory for one table (but that's used in the present
implementation anyway)
A wait for the old map to become quiescent, which would correspond
to the time used to do a lookup in the old table.
Would this be an acceptable extra cost?
Eivind.
[1] The present implementation is not guaranteed atomic for the
non-Windows case, though it will probably often be atomic in
practice.