[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...
Issue #14357 has been reported by vo.x (Vit Ondruch).
11 messages
2018/01/15
[#85364] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
[email protected] wrote:
[#85368] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
Eric Wong wrote:
[#85442] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Eric Wong <[email protected]> wrote:
[#85451] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Vladimir Makarov <vmakarov@...>
2018/02/06
On 02/06/2018 05:00 AM, Eric Wong wrote:
[#85455] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Vladimir Makarov <[email protected]> wrote:
[#84874] [Ruby trunk Bug#14360] Regression CSV#open method for writing from Ruby 2.4.3 to 2.5.0 — shevegen@...
Issue #14360 has been updated by shevegen (Robert A. Heiler).
3 messages
2018/01/15
[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...
Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).
10 messages
2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/23
[email protected] wrote:
[#85081] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
Eric Wong <[email protected]> wrote:
[#85082] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
> Thinking about this even more; I don't think it's possible to
[#85088] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — danieldasilvaferreira@...
Issue #13618 has been updated by dsferreira (Daniel Ferreira).
3 messages
2018/01/25
[#85107] [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? — eregontp@...
Issue #14222 has been updated by Eregon (Benoit Daloze).
3 messages
2018/01/25
[#85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/01/26
[ruby-core:85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
From:
Eric Wong <normalperson@...>
Date:
2018-01-26 19:13:43 UTC
List:
ruby-core #85136
[email protected] wrote: > In async, I called it `Async::Task`. I think task is a good > name for this kind of thing. In your case, you might want to > consider `Thread::Task`. Since, the lexicographic nesting is > similar to the logical nesting. I prefer shorter names; and I'm not sure if Thread::Task makes sense since it's an alternative to Thread (in some situations); not a helper to Thread (unlike Mutex/Queue/etc). > Regarding kqueue bugs. macOS kqueue implementation is > horrendous. So, `nio4r` doesn't use it AFAIK. Yes, there's also a select() implementation which should be a safe fallback for everybody (not scalable, of course). I'm not sure if OpenBSD/NetBSD/Dragonfly have acceptable kqueue implementations, nowadays, either (FreeBSD seems fine). I will add notes to guide porters into disabling kqueue support, either broadly or fine-grained (per-type), or better, eventually fixing their native kqueue implementations. I also intend to try aio-poll support in future Linux versions (currently under development). > Do you have explicit reactor, or is it implicit per-thread or > per-process? Implicit per-process, and lazily created. kqueue and epoll persistent data structures in the kernel are completely safe to use across multiple threads. select needs no persistent structure in the kernel. Userspace structures are of course done in a thread-safe way and will be adjusted for guilds or GVL removal. If guilds end up being what I expect them to be (implemented via native threads), reactor will likely remain per-process since FDs are still per-process. Some structures and locking will be adjusted for guilds, of course. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
