[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85616] Re: Why require autoconf 2.67+
— Vít Ondruch <v.ondruch@...>
2018/02/18
VGhpcyBjb3VsZCBoZWxwIHlvdSB0byBidWlsZCBSdWJ5IHdpdGggb2xkZXIgYXV0b2NvbmYgKDIu
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
[email protected] wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85470] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
From:
Eric Wong <normalperson@...>
Date:
2018-02-07 23:19:47 UTC
List:
ruby-core #85470
[email protected] wrote: > The GIL guarantees all C code is executed with the GIL held, so C code always perfectly sees effects performed by C code of other threads > (except rb_thread_call_without_gvl but it is not used here, is it?). Correct, GVL protects common cases (string/fixnum/etc) > In this case: is the code during a Hash lookup, after calling Ruby's #hash/#eql? expecting some state to not have changed since before the call? > If so, it should be enough to re-check that state after the call. Yes, probably doable. I thought about this while eating; but we can probably use rebuilds_num as a seqlock: unsigned int seq; retry: seq = tab->rebuilds_num; /* needs barriers */ ... ...->compare(a, b); /* may rebuild */ if (tab->rebuilds_num != seq) goto retry; Not free in terms of overhead, but should still be cheap and shouldn't need atomics on the reader side; only memory barriers to ensure correct ordering with some CPUs. > When growing/shrinking a Hash table, the GIL should be held, so that should be observed atomically by other threads. > Or is it the problem that #rehash needs to call back to Ruby code? Right, the rebuild is done entirely with the GVL held, so that's not a problem. It needs to update rebuild_num atomically for the above reader pseudocode to work, but that's a cold path. Vladimir: thoughts? Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
