From: Eric Wong Date: 2018-04-26T06:01:37+00:00 Subject: [ruby-core:86691] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid samuel@oriontransfer.org 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: