So, after all the discussion about epoll support in EM, has any work been done on it? For my projects, I can see a HUGE selling point to epoll/kqueue support. Kirk Haines
At one point Francis sent me an epoll implementation. I was unable to get it to compile. Sorry I haven''t had the opportunity to investigate this further, Francis. However, I think a unithreaded approach which makes repeated system calls so as to work in tandem with the Ruby scheduler will rob you of the general scalability benefits of epoll (in terms of performance. You''ll still get the benefits of high numbers of connections). Furthermore, an epoll specific implementation locks you into supporting Linux only. I would suggest running libevent inside another thread, coordinating activities over a socketpair, and having libevent read from/write to shared memory. Usage of shared memory can be synchronized over the socketpair, and once I/O is complete the resulting objects can be mapped directly into the Ruby interpreter. Thus nothing need run alongside the Ruby event loop, and all it would be used for is coordination of the shared memory space and receiving from or dispatching commands to libevent. Unfortunately Ruby uses sigprocmask() extensively. In order to make this approach function optionally pthread_sigmask would need to be used instead. Perhaps this would involve an RCR to merge Ruby 1.9''s threads.c (which I believe uses pthread_sigmask during multithread operation) into the 1.8branch. Without Ruby 1.9''s threads.c this approach would work but would be constantly interrupted by signals the Ruby interpreter uses for various reasons, since a signal mask couldn''t be set to block them. -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com 720-227-0129 ext. 202 On 6/5/07, Kirk Haines <wyhaines at gmail.com> wrote:> > So, after all the discussion about epoll support in EM, has any work > been done on it? > > For my projects, I can see a HUGE selling point to epoll/kqueue support. > > > Kirk Haines > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070605/aea53588/attachment.html
On 6/5/07, Tony Arcieri <tony at clickcaster.com> wrote:> > At one point Francis sent me an epoll implementation. I was unable to get > it to compile. Sorry I haven''t had the opportunity to investigate this > further, Francis. > > However, I think a unithreaded approach which makes repeated system calls > so as to work in tandem with the Ruby scheduler will rob you of the general > scalability benefits of epoll (in terms of performance. You''ll still get > the benefits of high numbers of connections). Furthermore, an epoll > specific implementation locks you into supporting Linux only. > > I would suggest running libevent inside another thread, coordinating > activities over a socketpair, and having libevent read from/write to shared > memory. Usage of shared memory can be synchronized over the socketpair, and > once I/O is complete the resulting objects can be mapped directly into the > Ruby interpreter. Thus nothing need run alongside the Ruby event loop, and > all it would be used for is coordination of the shared memory space and > receiving from or dispatching commands to libevent.I''ve heard about this approach (libevent in a thread) before and it doesn''t convince me because the extra pieces add considerable complexity and overhead. You mention two benefits: avoiding platform-specific implementations (because Niels has wrapped those up) and performance improvements. To the first point, you''re going around the block to get next door, because you have to add a lot of (platform-specific) stuff to wedge libevent into this environment. And to the second point, you''re assuming that thread-context switching, locks in shared memory, socketpair communications, and a signal-masking patch will add up to less of a performance loss than just hooking Ruby''s thread scheduler. It makes a lot more sense to me at this point to clean up the existing epoll implementation (which did no particular violence to the EM reactor''s current design) and have you all try it. Kqueue is not hard to add after that because it''s the same basic idea. For serious performance and scalability benefits on Windows, we''ll need to go to IOCP''s and do this right. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070606/98a5d3ec/attachment-0001.html