[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...

Issue #14723 has been updated by ko1 (Koichi Sasada).

13 messages 2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC — Eric Wong <normalperson@...> 2018/05/01

ko1@atdot.net wrote:

[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...

Issue #14767 has been updated by ko1 (Koichi Sasada).

9 messages 2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — Eric Wong <normalperson@...> 2018/05/17

ko1@atdot.net wrote:

[ruby-core:86871] Re: [Ruby trunk Misc#14735] thread-safe operations in a hash could be documented

From: Eric Wong <normalperson@...>
Date: 2018-05-04 00:16:50 UTC
List: ruby-core #86871
rr.rosas@gmail.com wrote:
> result = {} # assume this is thread-safe in MRI for now
> data_types.map do |data_type, processor|
>   Thread.start{ result[data_type] = processor.call }
> end.each &:join

It's only thread-safe in MRI if data_type is a common key type:

	String/Symbol/Integer/nil/true/false/Float

> Is it just by chance?

Yes, probably...

> By the way, the 'concurrent' gem seems to assume Hash is thread-safe in MRI as you can see here:

'thread_safe' hit problems with that assumption:

	https://bugs.ruby-lang.org/issues/14357

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next