[#86755] [Ruby trunk Feature#14723] [WIP] sleepy GC — normalperson@...
Issue #14723 has been reported by normalperson (Eric Wong).
6 messages
2018/04/29
[ruby-core:86691] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
From:
Eric Wong <normalperson@...>
Date:
2018-04-26 06:01:37 UTC
List:
ruby-core #86691
[email protected] wrote: > If you are unsure of a good definition for the reactor > pattern, I think this is a good one: > https://en.wikipedia.org/wiki/Reactor_pattern except the > assumption that you need to invert flow control which is not > necessary using fibers. Right, I was reading the Wikipedia page and that description does not resemble the implementation I have for this feature. > In my experience, experimenting with implementations that use > shared epoll/kqueue on a background thread Using a background thread is your mistake. Multiple foreground threads safely use epoll_wait or kevent on the SAME epoll or kqueue fd. It's perfectly safe to do that. Typical reactor is not designed to handle that :P If we eventually encounter contention, we can add more epoll or kqueue descriptors; but I doubt it'll ever come to that. Back to the diner analogy: multiple restaurant waiter can sit at the counter to wait if the cooks are slow and there's no diners placing new orders. > , the thread contention is a pretty big overhead, I think > somewhere between 5x and 10x overhead but I'd prefer to back > that up with real numbers. Not only that, the practical > implementation is more complicated since you need to implement > IPC, locking etc. IPC? Interprocess communication? What? There's no processes, here. No extra locking, either. The kernel already does locking, no point in doing it in luserspace. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
