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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>