[#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:85417] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
From:
Eric Wong <normalperson@...>
Date:
2018-02-05 21:42:19 UTC
List:
ruby-core #85417
[email protected] wrote: > Excited to see this awesome feature! I'm implemented > fiber-auto-schedule at ruby > userland([light](https://github.com/socketry/lightio)) few > month ago(using monkey patch). Due to ruby complexity IO API > (like: `getc`, `getbyte`, `put,c`, `putbyte`), it's hard to > implement these methods without C, the built-in `Threadlet` or > `Thread::Green` is all I want as a ruby user. (bad news for me > is my library have no meaning to exists). Thank you for your response. I agree a lot of the current IO stuff is difficult or costly to implement outside of C. I hope some dependencies on C can eventually be reduced; but stuff like supporting writev in IO#write_nonblock <https://bugs.ruby-lang.org/issues/14404> remind me some things are perhaps best done in C. Anyways lightio can be counted as another reason to implement this feature natively in core (along with previous efforts dating back to Neverblock), so perhaps lightio already served a great purpose :) > Two opinions: > The name `Threadlet` or `Thread::Green` both is easy to > understand and to guess it behaviour, so as a application > level user I think both is fine. I think the `Mutex`, > `ConditonVariable` needed to be `Thread::Green` aware, cause > if I write a thread-safe library using mutex, it's not make > sense if it can't work under `Thread::Green`. Yes, I am strongly leaning towards making mutex, cv and queues green-thread aware and I'm working on improving time representations in core to that end: https://bugs.ruby-lang.org/issues/14431 https://bugs.ruby-lang.org/issues/14452 Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>