I''m sorry if this has been asked before... I''m one of those types who''s too lazy to search and just wants to dive right in. So, I was looking over the underlying implementation today and noticed it was select() based, but the new version moves to Kernel#select. I noticed it still needs a native extension, but this native extension isn''t used for the actual socket multiplexing. I was curious as to why select, an interface which limits you to O(n) for n descriptors, is still being used. Is there any desire to take advantage of OS-specific high performance I/O interfaces (e.g. ones which provide constant time scalability), such as POSIX asynchronous I/O, Linux''s epoll, FreeBSD and OS X''s kqueues, Win32 I/O completion ports, Solaris I/O completion ports, etc. I worked on a large and complex networking project in C for some years and found myself spending the majority of the time researching how to hook into these various OS interfaces. I''d consider myself fairly proficient with most of them (with the exception of epoll and Solaris IOCP about which I know little/nothing) and am presently working with a group to redevelop the same project in Ruby instead of C, and EventMachine is a great fit for how it''s being implemented. So anyway, if there''s any interest in leveraging the native extension to hook into high performance platform-specific I/O interfaces, let me know... -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com (970) 232-4208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061011/9fba67d4/attachment.html
Long time listener first time caller. Aren''t the constant factors (ie: Ruby overhead) going to dominate the algorithmic factors with select()? At any rate, the performance implications of select are highly overstated (asy select code is way faster than threaded IO at "typical" volume, and not much slower than epoll at that volume; it only slows down when "n" gets huge). My experience is that select is more reliable cross-platform than any of the faster alternatives, as evidenced by me constantly having to fix libevent when I port code to OS X. On the other hand, pluggable event sources is kind of the reason for having an interface like EventMachine. =) I meant to write earlier, but EventMachine rocks, and thank you for writing it. Has anyone played with getting Drb working in it (I imagine hooking an EventMachine ruby up to a Rails process is one of the major things people get stymied by)? I tried, but Drb was more complicated than just sending Marshalled Ruby objects with a length word. On 10/11/06, Tony Arcieri <tony at clickcaster.com> wrote:> I''m sorry if this has been asked before... I''m one of those types who''s too > lazy to search and just wants to dive right in. > > So, I was looking over the underlying implementation today and noticed it > was select() based, but the new version moves to Kernel#select. I noticed > it still needs a native extension, but this native extension isn''t used for > the actual socket multiplexing. > > I was curious as to why select, an interface which limits you to O(n) for n > descriptors, is still being used. Is there any desire to take advantage of > OS-specific high performance I/O interfaces ( e.g. ones which provide > constant time scalability), such as POSIX asynchronous I/O, Linux''s epoll, > FreeBSD and OS X''s kqueues, Win32 I/O completion ports, Solaris I/O > completion ports, etc. > > I worked on a large and complex networking project in C for some years and > found myself spending the majority of the time researching how to hook into > these various OS interfaces. I''d consider myself fairly proficient with > most of them (with the exception of epoll and Solaris IOCP about which I > know little/nothing) and am presently working with a group to redevelop the > same project in Ruby instead of C, and EventMachine is a great fit for how > it''s being implemented. > > So anyway, if there''s any interest in leveraging the native extension to > hook into high performance platform-specific I/O interfaces, let me know... > > -- > Tony Arcieri > ClickCaster, Inc. > tony at clickcaster.com > (970) 232-4208 > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk > >
From: "Thomas Ptacek" <thomasptacek at gmail.com>> > Has anyone played with getting Drb working in it (I imagine hooking an > EventMachine ruby up to a Rails process is one of the major things > people get stymied by)? I tried, but Drb was more complicated than > just sending Marshalled Ruby objects with a length word.I had posted a month or two ago about my interest in adapting DRb to work with EventMachine. However, I haven''t made any progress (busy with other projects.) Regards, Bill
On 10/11/06, Tony Arcieri <tony at clickcaster.com> wrote:> > I''m sorry if this has been asked before... I''m one of those types who''s > too lazy to search and just wants to dive right in. > > So, I was looking over the underlying implementation today and noticed it > was select() based, but the new version moves to Kernel#select. I noticed > it still needs a native extension, but this native extension isn''t used for > the actual socket multiplexing. > > I was curious as to why select, an interface which limits you to O(n) for > n descriptors, is still being used. Is there any desire to take advantage > of OS-specific high performance I/O interfaces ( e.g. ones which provide > constant time scalability), such as POSIX asynchronous I/O, Linux''s epoll, > FreeBSD and OS X''s kqueues, Win32 I/O completion ports, Solaris I/O > completion ports, etc. > > I worked on a large and complex networking project in C for some years and > found myself spending the majority of the time researching how to hook into > these various OS interfaces. I''d consider myself fairly proficient with > most of them (with the exception of epoll and Solaris IOCP about which I > know little/nothing) and am presently working with a group to redevelop the > same project in Ruby instead of C, and EventMachine is a great fit for how > it''s being implemented. > > So anyway, if there''s any interest in leveraging the native extension to > hook into high performance platform-specific I/O interfaces, let me know...Tony, you were evidently having some trouble posting to the list earlier so I responded to you privately. For the benefit of everyone else, the gist of my response was that EM was definitely designed to accomodate swapping in high-performance platform-specific I/O mechanisms, using #ifdeffed code paths. I worked on IOCP at one point and never finished it (that would be of great interest, if anyone wants to work on it). I''ve done epoll experimentally and it works. Kqueue would also be easy. I don''t know what it would take to do Solaris doors, that''s something I''ve never done myself. The problem of course is working with Ruby''s green threads. Practically speaking, you really can''t block in native code for any amount of time without messing up Ruby (I think 5 mills would be the upper limit- Ruby''s internal setitimer tick is 10 mills). Select really does work rather well for the vast majority of applications, but of course there is that high-performance and/or high-scalability edge that EM really should address. After all the charter of EM is to get the very best performance and scalability available in Ruby, and to do so without threads. Tangentially, since Thomas mentioned it, we should be integrating other kinds of events, like processes, signals, file/keyboard I/O, and GUI events into this product eventually. DRb: Bill, I do hope you get a chance to keep working on this. As far as Rails integration is concerned, I think I''d like to do this through an asynchronous message-queueing broker. I''m busy writing one on top of EM now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061011/2c468299/attachment.html
So, to get around the green threads issue, is it possible to use POSIX asynchronous I/O (i.e. the aio_* family) and have Ruby to receive events via POSIX realtime signal queues? Last I looked, signals in Ruby are still being handled through signal()-configured handlers, but it would get around the issue of using a blocking call to receive events... instead they''d be delivered to the Ruby interpreter directly. I''m fairly certain sigwaitinfo() is needed to receive event information, at least on Linux (FreeBSD allows the use of kqueues to receive POSIX aio event completion notifications), and I''m guessing Ruby likely doesn''t wrap this at all, but I figured I should at least ask. I don''t know enough about the internals of the Ruby interpreter to know if this is even possible, but it''s the best way I can think of to get the Ruby green threads scheduler and I/O to play nicely together, at least on Linux, and the EventMachine seems fairly amenable to async I/O. On 10/11/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 10/11/06, Tony Arcieri <tony at clickcaster.com> wrote: > > > > I''m sorry if this has been asked before... I''m one of those types who''s > > too lazy to search and just wants to dive right in. > > > > So, I was looking over the underlying implementation today and noticed > > it was select() based, but the new version moves to Kernel#select. I > > noticed it still needs a native extension, but this native extension isn''t > > used for the actual socket multiplexing. > > > > I was curious as to why select, an interface which limits you to O(n) > > for n descriptors, is still being used. Is there any desire to take > > advantage of OS-specific high performance I/O interfaces ( e.g. ones > > which provide constant time scalability), such as POSIX asynchronous I/O, > > Linux''s epoll, FreeBSD and OS X''s kqueues, Win32 I/O completion ports, > > Solaris I/O completion ports, etc. > > > > I worked on a large and complex networking project in C for some years > > and found myself spending the majority of the time researching how to hook > > into these various OS interfaces. I''d consider myself fairly proficient > > with most of them (with the exception of epoll and Solaris IOCP about which > > I know little/nothing) and am presently working with a group to redevelop > > the same project in Ruby instead of C, and EventMachine is a great fit for > > how it''s being implemented. > > > > So anyway, if there''s any interest in leveraging the native extension to > > hook into high performance platform-specific I/O interfaces, let me know... > > > > Tony, you were evidently having some trouble posting to the list earlier > so I responded to you privately. For the benefit of everyone else, the gist > of my response was that EM was definitely designed to accomodate swapping > in high-performance platform-specific I/O mechanisms, using #ifdeffed code > paths. I worked on IOCP at one point and never finished it (that would be of > great interest, if anyone wants to work on it). I''ve done epoll > experimentally and it works. Kqueue would also be easy. I don''t know what it > would take to do Solaris doors, that''s something I''ve never done myself. > > The problem of course is working with Ruby''s green threads. Practically > speaking, you really can''t block in native code for any amount of time > without messing up Ruby (I think 5 mills would be the upper limit- Ruby''s > internal setitimer tick is 10 mills). > > Select really does work rather well for the vast majority of applications, > but of course there is that high-performance and/or high-scalability edge > that EM really should address. After all the charter of EM is to get the > very best performance and scalability available in Ruby, and to do so > without threads. > > Tangentially, since Thomas mentioned it, we should be integrating other > kinds of events, like processes, signals, file/keyboard I/O, and GUI events > into this product eventually. > > DRb: Bill, I do hope you get a chance to keep working on this. As far as > Rails integration is concerned, I think I''d like to do this through an > asynchronous message-queueing broker. I''m busy writing one on top of EM now. > > > > _______________________________________________ > 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/20061012/3ce4c886/attachment-0001.html
Another approach (if the Ruby interpreter is remotely thread safe, which I''m guessing it''s not) is to spawn a native thread in the C code, then use a socketpair() or similar platform mechanism which can be mixed in with both the blocking event monitor call , run the blocking event monitor in the new thread, and have the parent thread monitor the IPC channel with select() to wait for incoming events. On 10/12/06, Tony Arcieri <tony at clickcaster.com> wrote:> > So, to get around the green threads issue, is it possible to use POSIX > asynchronous I/O (i.e. the aio_* family) and have Ruby to receive events > via POSIX realtime signal queues? Last I looked, signals in Ruby are still > being handled through signal()-configured handlers, but it would get around > the issue of using a blocking call to receive events... instead they''d be > delivered to the Ruby interpreter directly. I''m fairly certain > sigwaitinfo() is needed to receive event information, at least on Linux > (FreeBSD allows the use of kqueues to receive POSIX aio event completion > notifications), and I''m guessing Ruby likely doesn''t wrap this at all, but I > figured I should at least ask. > > I don''t know enough about the internals of the Ruby interpreter to know if > this is even possible, but it''s the best way I can think of to get the Ruby > green threads scheduler and I/O to play nicely together, at least on Linux, > and the EventMachine seems fairly amenable to async I/O. > > On 10/11/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote: > > > On 10/11/06, Tony Arcieri <tony at clickcaster.com> wrote: > > > > > > I''m sorry if this has been asked before... I''m one of those types > > > who''s too lazy to search and just wants to dive right in. > > > > > > So, I was looking over the underlying implementation today and noticed > > > it was select() based, but the new version moves to Kernel#select. I > > > noticed it still needs a native extension, but this native extension isn''t > > > used for the actual socket multiplexing. > > > > > > I was curious as to why select, an interface which limits you to O(n) > > > for n descriptors, is still being used. Is there any desire to take > > > advantage of OS-specific high performance I/O interfaces ( e.g. ones > > > which provide constant time scalability), such as POSIX asynchronous I/O, > > > Linux''s epoll, FreeBSD and OS X''s kqueues, Win32 I/O completion ports, > > > Solaris I/O completion ports, etc. > > > > > > I worked on a large and complex networking project in C for some years > > > and found myself spending the majority of the time researching how to hook > > > into these various OS interfaces. I''d consider myself fairly proficient > > > with most of them (with the exception of epoll and Solaris IOCP about which > > > I know little/nothing) and am presently working with a group to redevelop > > > the same project in Ruby instead of C, and EventMachine is a great fit for > > > how it''s being implemented. > > > > > > So anyway, if there''s any interest in leveraging the native extension > > > to hook into high performance platform-specific I/O interfaces, let me > > > know... > > > > > > > > Tony, you were evidently having some trouble posting to the list earlier > > so I responded to you privately. For the benefit of everyone else, the gist > > of my response was that EM was definitely designed to accomodate swapping > > in high-performance platform-specific I/O mechanisms, using #ifdeffed code > > paths. I worked on IOCP at one point and never finished it (that would be of > > great interest, if anyone wants to work on it). I''ve done epoll > > experimentally and it works. Kqueue would also be easy. I don''t know what it > > would take to do Solaris doors, that''s something I''ve never done myself. > > > > The problem of course is working with Ruby''s green threads. Practically > > speaking, you really can''t block in native code for any amount of time > > without messing up Ruby (I think 5 mills would be the upper limit- Ruby''s > > internal setitimer tick is 10 mills). > > > > Select really does work rather well for the vast majority of > > applications, but of course there is that high-performance and/or > > high-scalability edge that EM really should address. After all the charter > > of EM is to get the very best performance and scalability available in Ruby, > > and to do so without threads. > > > > Tangentially, since Thomas mentioned it, we should be integrating other > > kinds of events, like processes, signals, file/keyboard I/O, and GUI events > > into this product eventually. > > > > DRb: Bill, I do hope you get a chance to keep working on this. As far as > > Rails integration is concerned, I think I''d like to do this through an > > asynchronous message-queueing broker. I''m busy writing one on top of EM now. > > > > > > > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ eventmachine-talk<http://rubyforge.org/mailman/listinfo/eventmachine-talk> > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061012/baeb848c/attachment.html