[#83773] [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769 — usa@...
Issue #14108 has been updated by usa (Usaku NAKAMURA).
9 messages
2017/11/15
[#83774] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
usa@garbagecollect.jp wrote:
[#83775] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— "U.NAKAMURA" <usa@...>
2017/11/15
Hi, Eric
[#83779] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#83781] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— "U.NAKAMURA" <usa@...>
2017/11/15
Hi, Eric,
[#83782] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[ruby-core:83808] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
From:
Eric Wong <normalperson@...>
Date:
2017-11-17 21:48:46 UTC
List:
ruby-core #83808
Btw, reiterating what I wrote privately, the correct way to do this would be: > Dir#read: > release GVL > acquire dir_data.lock > readdir() call /* dirent pointer returned */ > copy dirent result to tmp > release dir_data.lock /* done using dirent */ > acquire GVL > make String from tmp Too much engineering effort and the performance hit would suck (even more than it does now). We may consider using non-portable getdents/getdents64 syscalls on some platforms (Linux, FreeBSD) directly for Ruby 2.6/3.x. That would allow us to avoid introducing dir_data.lock and extra copy, but it's too late for 2.5. readdir(3) is high-level stdio crap; we've already purged most of the stdio overhead in io.c for 1.9+; so maybe we can continue that trend in dir.c. Of course, read(2)/write(2) are portable while getdents(2) isn't :< However, opendir can safely release GVL we should be able to get that into 2.5... Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>