From tony at medioh.com Wed Aug 6 15:42:38 2008 From: tony at medioh.com (Tony Arcieri) Date: Wed, 6 Aug 2008 13:42:38 -0600 Subject: [Rev-talk] flow In-Reply-To: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> Message-ID: On Wed, Aug 6, 2008 at 1:40 PM, ry wrote: > hey > i wrote a new web server today. it only works on yarv and it requires > rev but it's mostly written in ruby (instead of c). > > http://github.com/ry/flow/tree/master > > it uses fibers and not threads. (maybe i'll add deferred requets > later) > it should handle chunked uploads (and soon chunked responses) > it does pipelined requests too, i think > but not ssl. > Sounds awesome, especially now that Rails supports Ruby 1.9. What kind of performance are you getting with it? -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Wed Aug 6 15:54:34 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Wed, 6 Aug 2008 13:54:34 -0600 Subject: [Rev-talk] flow In-Reply-To: References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> Message-ID: <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> Why does it require 1.9? Just wondering. -R > Sounds awesome, especially now that Rails supports Ruby 1.9. > > What kind of performance are you getting with it? From tony at medioh.com Wed Aug 6 15:55:57 2008 From: tony at medioh.com (Tony Arcieri) Date: Wed, 6 Aug 2008 13:55:57 -0600 Subject: [Rev-talk] flow In-Reply-To: <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> Message-ID: On Wed, Aug 6, 2008 at 1:54 PM, Roger Pack wrote: > Why does it require 1.9? Just wondering. > Not sure if ry is on rev-talk so I'll CC him. He's using Fibers for handling requests, which is a Ruby 1.9-only feature. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Wed Aug 6 17:49:50 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Wed, 6 Aug 2008 15:49:50 -0600 Subject: [Rev-talk] flow In-Reply-To: <3ae7f4480808061301p4ee1a01bw95449243aef30c21@mail.gmail.com> References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> <3ae7f4480808061301p4ee1a01bw95449243aef30c21@mail.gmail.com> Message-ID: <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> Fibers are definitely cooler :) I did some work recently on integrating a fibered web server with a fibered DB and it seemed to have success: here are some links of interest: http://oldmoe.blogspot.com/ # he's been researching into it a lot :P http://209.85.173.104/search?q=cache:EcGf70nMwgwJ:betterlogic.com/roger/%3Fcat%3D35+asymy&hl=en&ct=clnk&cd=3&gl=us&client=firefox-a # my own work on it--deprecated so I deleted it, but it's still around. I'd say fibers definitely have promise--if only as a way to avoid the pain of blocking DB IO. Note also that if you want to run asymy under rev you could do it using rev_em in the contrib folder of SVN. It seems to work. On Wed, Aug 6, 2008 at 2:01 PM, ryah dahl wrote: >> On Wed, Aug 6, 2008 at 1:54 PM, Roger Pack >> wrote: >>> >>> Why does it require 1.9? Just wondering. > > it uses Fibers. Which could be replaced with Threads, I guess, and > make it 1.8 compatible. But that would be less cool. > > Your request is dispatched as soon as the headers are parsed, but the > body of the request will still need to be read. In order to do this > you call > env["rack.input"].read > This yields the Fiber and jumps back into the request loop. Once data > is available it resumes the fiber. > > What would be cool is to break with the Rack protocol and provide a > completely evented interface for web frameworks (and do not use > Fibers). You'd just have on_body_chunk() callbacks and stuff. but i > guess people won't use it unless they can't just plug-in their old > stuff, so I'm doing the rack interface. Yeah a completely evented interface would definitely be the fastest thing on the block :) Unfortunately it's somewhat unwieldy if your current code is something like a = School.find(1) if a.name == 'greg' # do something a.steps[0].name = 'fred' end would then have to be rewritten like School.find(a) do |a| if a.name == 'greg' a.steps[0] do |step| step.name = 'fred' end end end so really...layered. Plus learned recently that named blocks [which is what you'd have to use here--or is it?] are expensive in Ruby, so...fibers seem a much nicer solution :) Also note that rev comes packages with a fibered mongrel example, though I'd assume it's similar to yours [and yours might be faster]. -R > > ry > From tony at medioh.com Wed Aug 6 18:43:16 2008 From: tony at medioh.com (Tony Arcieri) Date: Wed, 6 Aug 2008 16:43:16 -0600 Subject: [Rev-talk] flow In-Reply-To: <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> <3ae7f4480808061301p4ee1a01bw95449243aef30c21@mail.gmail.com> <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> Message-ID: On Wed, Aug 6, 2008 at 3:49 PM, Roger Pack wrote: > Yeah a completely evented interface would definitely be the fastest > thing on the block :) > Unfortunately it's somewhat unwieldy if your current code is something like > a = School.find(1) > if a.name == 'greg' > # do something > a.steps[0].name = 'fred' > end > > would then have to be rewritten like > School.find(a) do |a| > if a.name == 'greg' > a.steps[0] do |step| > step.name = 'fred' > end > end > end > > so really...layered. The real problem here is inversion of control that comes from any framework which is fundamentally Reactor based. What Fibers allow you to do is build synchronous interfaces on top of a Reactor framework. That's specifically what Revactor, the Actor framework I built on top of Rev, is designed to do. However, it wouldn't be too difficult to write synchronous wrappers for async database libraries on top of something like Flow, and it'd probably be a lot more lightweight than Revactor. In your example, the: a = School.find(1) ...would "block" as the async DB library makes a request. The fiber making the request would yield, and only be resumed after the async DB code has completed the query and processed the result. In fact, you could probably write an ActiveRecord adapter on top of such an API. Also note that rev comes packages with a fibered mongrel example, > though I'd assume it's similar to yours [and yours might be faster]. > The Fibered mongrel example actually comes with Revactor (since Revactor takes care of all the I/O and Fiber scheduling), although I'm guessing it probably performs a lot worse than Flow. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ry at tinyclouds.org Wed Aug 6 18:43:57 2008 From: ry at tinyclouds.org (ryah dahl) Date: Thu, 7 Aug 2008 00:43:57 +0200 Subject: [Rev-talk] flow In-Reply-To: <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> <3ae7f4480808061301p4ee1a01bw95449243aef30c21@mail.gmail.com> <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> Message-ID: <3ae7f4480808061543j2bfad63qc216ae21bacbd6b4@mail.gmail.com> On Wed, Aug 6, 2008 at 11:49 PM, Roger Pack > here are some links of interest: > http://oldmoe.blogspot.com/ # he's been researching into it a lot :P actually i've been emailing him about it and wrote this after being annoyed that i couldn't access my event loop in ebb from ruby. > Yeah a completely evented interface would definitely be the fastest > thing on the block :) > Unfortunately it's somewhat unwieldy if your current code is something like > a = School.find(1) > if a.name == 'greg' > # do something > a.steps[0].name = 'fred' > end > > would then have to be rewritten like > School.find(a) do |a| > if a.name == 'greg' > a.steps[0] do |step| > step.name = 'fred' > end > end > end what if you had something where each class was an action. and the variables that were needed inside the template were methods. class Index < GetRequest def users Users.find(:all) end def posts Posts.find(:all, :last_week) end TEMPLATE = "/templates/users.erb" end (OR something) but if you didn't use ActiveRecord but instead something else where find(:all) was nonblocking and returned, say, a rev io watcher to the database socket. When it completed it loads the results into @users and @posts then renders. structuring a web app in something like this would allow you to be very fast. > Also note that rev comes packages with a fibered mongrel example, > though I'd assume it's similar to yours [and yours might be faster]. i think it's a client not a server? ry From roger.pack at leadmediapartners.com Wed Aug 6 19:19:22 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Wed, 6 Aug 2008 17:19:22 -0600 Subject: [Rev-talk] flow In-Reply-To: References: <8a573f7a-df8d-4288-b7e4-398f666d236e@c65g2000hsa.googlegroups.com> <966599840808061254i22c47bb7k78aa68a4ce9157ac@mail.gmail.com> <3ae7f4480808061301p4ee1a01bw95449243aef30c21@mail.gmail.com> <966599840808061449h65902f07q27fb048101ec1521@mail.gmail.com> Message-ID: <966599840808061619v50cdf66dvd2279c5d5729c672@mail.gmail.com> On Wed, Aug 6, 2008 at 4:43 PM, Tony Arcieri wrote: > On Wed, Aug 6, 2008 at 3:49 PM, Roger Pack > wrote: >> >> Yeah a completely evented interface would definitely be the fastest >> thing on the block :) >> Unfortunately it's somewhat unwieldy if your current code is something >> like >> a = School.find(1) >> if a.name == 'greg' >> # do something >> a.steps[0].name = 'fred' >> end >> >> would then have to be rewritten like >> School.find(a) do |a| >> if a.name == 'greg' >> a.steps[0] do |step| >> step.name = 'fred' >> end >> end >> end >> >> so really...layered. > > The real problem here is inversion of control that comes from any framework > which is fundamentally Reactor based. > > What Fibers allow you to do is build synchronous interfaces on top of a > Reactor framework. That's specifically what Revactor, the Actor framework I > built on top of Rev, is designed to do. > > However, it wouldn't be too difficult to write synchronous wrappers for > async database libraries on top of something like Flow, and it'd probably be > a lot more lightweight than Revactor. Yeah I think that's what we're all advocating. A revactor style implementation for those pesky blocking DB calls. Come to think of it, this is indeed remarkably similar to revactor. =R From roger.pack at leadmediapartners.com Thu Aug 7 13:28:09 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Thu, 7 Aug 2008 11:28:09 -0600 Subject: [Rev-talk] Fwd: Nonblocking I/O for Web Applications In-Reply-To: <3ae7f4480808071020u68145c17l4b80b006985fcf30@mail.gmail.com> References: <4cb4766d0808040729p440775cne580527923570c2f@mail.gmail.com> <3ae7f4480808040949s2d4adb8cua81ad3da517bf55b@mail.gmail.com> <4cb4766d0808041015q1264587axe8f29207a0bd14be@mail.gmail.com> <3ae7f4480808050723u6049d53cn83b9e58160e4c2f7@mail.gmail.com> <4cb4766d0808051003s7781c689uaa9266d36f2ecc40@mail.gmail.com> <3ae7f4480808061225w5baf90f9l14752595912bc7e6@mail.gmail.com> <4cb4766d0808061456n55b1167o1d129237791b9771@mail.gmail.com> <3ae7f4480808071020u68145c17l4b80b006985fcf30@mail.gmail.com> Message-ID: <966599840808071028k35955fc8s35bbcb5fe4b0de40@mail.gmail.com> Fast is good. I fear for it's adoptability but hey, if you want speed... In other news, got this today: ~/dev gem install rev ERROR: Error installing rev: revactor requires Ruby version >= 1.9.0 Hmm. -R ---------- Forwarded message ---------- From: ryah dahl Date: Thu, Aug 7, 2008 at 11:20 AM Subject: Re: Nonblocking I/O for Web Applications To: "Muhammad A. Ali" Cc: Roger Pack This app http://github.com/ry/flow/tree/ac2336da53245a2dd4b9507a0a42e85f5afa5837/test.rb demonstrates a hooking something into the event loop during app.call() and returning to the response later. this is James Tucker's idea - he has a similar application working with Thin at http://github.com/raggi/thin/tree/97f5e58c78cfafdb4aca446de1771da6b0de7878/example/async_app.ru So you should be able to what you suggest (http://oldmoe.blogspot.com/2008/08/case-for-nonblocking-ruby-stack.html) with either James's Thin branch or my "flow" thing. Probably the API is going to change, though. On Wed, Aug 6, 2008 at 11:56 PM, Muhammad A. Ali wrote: > Wow, that fast? > > Will try it now > > On Wed, Aug 6, 2008 at 10:25 PM, ryah dahl wrote: >> >> hey. >> i wrote you a web server >> maybe it works? >> ry > > From roger.pack at leadmediapartners.com Thu Aug 7 19:25:31 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Thu, 7 Aug 2008 17:25:31 -0600 Subject: [Rev-talk] thoughts Message-ID: <966599840808071625r3e7b0879y2a824bcfa9c28842@mail.gmail.com> A couple of thoughts. Should on_resolve_failed call on_close by default? That might be good for newbies but also slightly confusing at the same time, since when you override it it would no longer call on_close. I'd imagine with proper documentation it wouldn't cause too much grief. Also should we add an on_resolve call? Or is that too internal? [It would be useful for connection timeouts, but...may not be too generically useful]. I'll probably next work on adding connection timeouts and liveness timeouts to rev_em. Thanks! -R From lists at daesan.com Sat Aug 9 09:40:31 2008 From: lists at daesan.com (Dae San Hwang) Date: Sat, 9 Aug 2008 22:40:31 +0900 Subject: [Rev-talk] Rev on Solaris Message-ID: Hi. "rev" seems to have some issues in Solaris. Whenever I attach "Rev::TCPServer" to an event loop and make connection, I get the following error. /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/listener.rb: 35:in `accept_nonblock': Resource temporarily unavailable - accept(2) (Errno::EAGAIN) from /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/ listener.rb:35:in `on_readable' from /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/ loop.rb:98:in `run_once' from /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/ loop.rb:98:in `run' from test.rb:67:in `
' I am running OpenSolaris snv_93 and using gcc and ruby 1.9.0. Installation(via gem) went without a problem though. daesan From ry at tinyclouds.org Sat Aug 9 11:26:42 2008 From: ry at tinyclouds.org (ryah dahl) Date: Sat, 9 Aug 2008 17:26:42 +0200 Subject: [Rev-talk] rev 0.2.2 and MRI Message-ID: <3ae7f4480808090826gc359a7r6892a333f6656633@mail.gmail.com> Should rev be working on MRI? gcc -I. -I. -I/home/ryan/local/ruby-1.8.7/lib/ruby/1.8/i686-linux -I. -DRUBY_VERSION_CODE=187 -DHAVE_RB_STR_SET_LEN -DHAVE_RB_STR_SET_LEN -DHAVE_SYS_SELECT_H -DEV_USE_SELECT -DHAVE_POLL_H -DEV_USE_POLL -DHAVE_SYS_EPOLL_H -DEV_USE_EPOLL -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -DHAVE_LINUX_PROCFS -D_FILE_OFFSET_BITS=64 -fPIC -g -O2 -c rev_io_watcher.c rev_io_watcher.c: In function 'Rev_IOWatcher_initialize': rev_io_watcher.c:93: error: 'rb_io_t' has no member named 'fd' make: *** [rev_io_watcher.o] Error 1 ruby 1.8.7 (2008-05-31 patchlevel 0) [i686-linux] ry From roger.pack at leadmediapartners.com Sat Aug 9 14:09:25 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Sat, 9 Aug 2008 12:09:25 -0600 Subject: [Rev-talk] Rev on Solaris In-Reply-To: References: Message-ID: <966599840808091109p325e063x3b3d05f98cf23743@mail.gmail.com> I take it that normal TCPSocket connections work? On Sat, Aug 9, 2008 at 7:40 AM, Dae San Hwang wrote: > Hi. > > "rev" seems to have some issues in Solaris. Whenever I attach > "Rev::TCPServer" to an event loop and make connection, I get the following > error. > > /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/listener.rb:35:in > `accept_nonblock': Resource temporarily unavailable - accept(2) > (Errno::EAGAIN) > from > /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/listener.rb:35:in > `on_readable' > from > /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/loop.rb:98:in > `run_once' > from > /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/loop.rb:98:in `run' > from test.rb:67:in `
' > > I am running OpenSolaris snv_93 and using gcc and ruby 1.9.0. > Installation(via gem) went without a problem though. > > daesan > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk > From roger.pack at leadmediapartners.com Sat Aug 9 15:23:17 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Sat, 9 Aug 2008 13:23:17 -0600 Subject: [Rev-talk] Nonblocking I/O for Web Applications In-Reply-To: <4cb4766d0808080529o20bfad86o971edbb23e1a298@mail.gmail.com> References: <4cb4766d0808040729p440775cne580527923570c2f@mail.gmail.com> <3ae7f4480808040949s2d4adb8cua81ad3da517bf55b@mail.gmail.com> <4cb4766d0808041015q1264587axe8f29207a0bd14be@mail.gmail.com> <3ae7f4480808050723u6049d53cn83b9e58160e4c2f7@mail.gmail.com> <4cb4766d0808051003s7781c689uaa9266d36f2ecc40@mail.gmail.com> <3ae7f4480808061225w5baf90f9l14752595912bc7e6@mail.gmail.com> <4cb4766d0808061456n55b1167o1d129237791b9771@mail.gmail.com> <3ae7f4480808071020u68145c17l4b80b006985fcf30@mail.gmail.com> <4cb4766d0808080529o20bfad86o971edbb23e1a298@mail.gmail.com> Message-ID: <966599840808091223x6b06d471q89e91352aa2bd56a@mail.gmail.com> YMMV but rev SVN might be faster. -=R On Fri, Aug 8, 2008 at 6:29 AM, Muhammad A. Ali wrote: > I have managed to hook into the eventloop with flow. I am using it now to do > the db operations. > > I am having a problem though with rev spitting errors at me randomly (will > get back to you with a stack trace) > > I also noticed that I am getting much more performance using Francis' > monorail server partially due to the fact that it is mostly C, but also due > to the fact that EM is faster than Rev (so says Tony) From tony at medioh.com Mon Aug 11 19:10:15 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 11 Aug 2008 17:10:15 -0600 Subject: [Rev-talk] thoughts In-Reply-To: <966599840808071625r3e7b0879y2a824bcfa9c28842@mail.gmail.com> References: <966599840808071625r3e7b0879y2a824bcfa9c28842@mail.gmail.com> Message-ID: On Thu, Aug 7, 2008 at 5:25 PM, Roger Pack wrote: > Should on_resolve_failed call on_close by default? That might be good > for newbies but also slightly confusing at the same time, since when > you override it it would no longer call on_close. I'd imagine with > proper documentation it wouldn't cause too much grief. Not really sure about this one. It might be good not to do it just to minimize the number of funcalls being made. Also, if resolution fails the connection was never open in the first place, so I don't think it's necessarily correct per the method name. > Also should we add an on_resolve call? Or is that too internal? [It > would be useful for connection timeouts, but...may not be too > generically useful]. > That sounds as if it might be useful. Perhaps it could be used as part of converting Rev::Sockets to allow creating with .new before the socket is opened (i.e. you could have a Rev::Socket#open method that on_resolve calls per default.) > I'll probably next work on adding connection timeouts and liveness > timeouts to rev_em. > Cool -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Aug 11 19:53:31 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 11 Aug 2008 17:53:31 -0600 Subject: [Rev-talk] Rev on Solaris In-Reply-To: References: Message-ID: On Sat, Aug 9, 2008 at 7:40 AM, Dae San Hwang wrote: > Hi. > > "rev" seems to have some issues in Solaris. Whenever I attach > "Rev::TCPServer" to an event loop and make connection, I get the following > error. > > /usr/local/lib/ruby/gems/1.9.0/gems/rev-0.2.2/lib/rev/listener.rb:35:in > `accept_nonblock': Resource temporarily unavailable - accept(2) > (Errno::EAGAIN) > Interesting... it appears Solaris is flagging the listener socket as readable even when it isn't. Not having access to a Solaris system anymore this is a somewhat hard problem for me to debug. However, the current HEAD revision of the Subversion repository is now configured to swallow Errno::EAGAIN when the Socket calls #accept_nonblock, but emits a warning. Can you give this a try and see if it works around the problem? If you see a bunch of: warning: listener socket spuriously readable ...messages being emitted in a loop then the problem can't be solved simply by swallowing Errno::EAGAIN and I'll have to look for a better solution. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Aug 11 20:15:58 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 11 Aug 2008 18:15:58 -0600 Subject: [Rev-talk] Fwd: Nonblocking I/O for Web Applications In-Reply-To: <966599840808071028k35955fc8s35bbcb5fe4b0de40@mail.gmail.com> References: <4cb4766d0808040729p440775cne580527923570c2f@mail.gmail.com> <3ae7f4480808040949s2d4adb8cua81ad3da517bf55b@mail.gmail.com> <4cb4766d0808041015q1264587axe8f29207a0bd14be@mail.gmail.com> <3ae7f4480808050723u6049d53cn83b9e58160e4c2f7@mail.gmail.com> <4cb4766d0808051003s7781c689uaa9266d36f2ecc40@mail.gmail.com> <3ae7f4480808061225w5baf90f9l14752595912bc7e6@mail.gmail.com> <4cb4766d0808061456n55b1167o1d129237791b9771@mail.gmail.com> <3ae7f4480808071020u68145c17l4b80b006985fcf30@mail.gmail.com> <966599840808071028k35955fc8s35bbcb5fe4b0de40@mail.gmail.com> Message-ID: Bizzare, it's trying to install Revactor when you gem install rev? That's quite odd, considering the gem dependencies go the other way around (Revactor depends on Rev but not vice versa) On Thu, Aug 7, 2008 at 11:28 AM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > Fast is good. I fear for it's adoptability but hey, if you want speed... > > > In other news, got this today: > ~/dev gem install rev > ERROR: Error installing rev: > revactor requires Ruby version >= 1.9.0 > > Hmm. > -R > > > ---------- Forwarded message ---------- > From: ryah dahl > Date: Thu, Aug 7, 2008 at 11:20 AM > Subject: Re: Nonblocking I/O for Web Applications > To: "Muhammad A. Ali" > Cc: Roger Pack > > > This app > > http://github.com/ry/flow/tree/ac2336da53245a2dd4b9507a0a42e85f5afa5837/test.rb > demonstrates a hooking something into the event loop during app.call() > and returning to the response later. > > this is James Tucker's idea - he has a similar application working with > Thin at > > http://github.com/raggi/thin/tree/97f5e58c78cfafdb4aca446de1771da6b0de7878/example/async_app.ru > > So you should be able to what you suggest > (http://oldmoe.blogspot.com/2008/08/case-for-nonblocking-ruby-stack.html) > with either James's Thin branch or my "flow" thing. Probably the API > is going to change, though. > > > > On Wed, Aug 6, 2008 at 11:56 PM, Muhammad A. Ali wrote: > > Wow, that fast? > > > > Will try it now > > > > On Wed, Aug 6, 2008 at 10:25 PM, ryah dahl wrote: > >> > >> hey. > >> i wrote you a web server > >> maybe it works? > >> ry > > > > > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk > -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Aug 11 20:27:21 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 11 Aug 2008 18:27:21 -0600 Subject: [Rev-talk] rev 0.2.2 and MRI In-Reply-To: <3ae7f4480808090826gc359a7r6892a333f6656633@mail.gmail.com> References: <3ae7f4480808090826gc359a7r6892a333f6656633@mail.gmail.com> Message-ID: On Sat, Aug 9, 2008 at 9:26 AM, ryah dahl wrote: > Should rev be working on MRI? > > rev_io_watcher.c: In function 'Rev_IOWatcher_initialize': > rev_io_watcher.c:93: error: 'rb_io_t' has no member named 'fd' > Yes, it certainly should, however this appears to be a 1.8.7 incompatibility due to backported changes from Ruby 1.9. *sigh* You might try grabbing HEAD and see if that builds for you on 1.8.7 successfully. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Tue Aug 12 14:41:34 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Tue, 12 Aug 2008 12:41:34 -0600 Subject: [Rev-talk] dns resolution Message-ID: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> I wonder if it would be possible to integrate libevent's own asynch DNS library in rev somehow. Heck if we're going that deep then I guess we could even write a wrapper for their HTTP server :) Take care. -R http://www.monkey.org/~provos/libevent/doxygen-1.4.3/ From tony at medioh.com Tue Aug 12 14:45:21 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 12 Aug 2008 12:45:21 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> Message-ID: On Tue, Aug 12, 2008 at 12:41 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > I wonder if it would be possible to integrate libevent's own asynch > DNS library in rev somehow. > That might be a bit difficult considering that Rev uses libev's native API without libevent compat. Are you having problems with Rev's pure Ruby async DNS? -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Tue Aug 12 15:43:14 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Tue, 12 Aug 2008 13:43:14 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> Message-ID: <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> Oh for some reason I thought it was using libevent not libev. I have no idea what the status of libev is for windows. I do hope it's something better than using select, since I think we're bound to 64 ports max on select, since we use the old msvcrt lib or something. Even resetting FD_SETSIZE didn't help last time I tried it. -R On Tue, Aug 12, 2008 at 12:45 PM, Tony Arcieri wrote: > On Tue, Aug 12, 2008 at 12:41 PM, Roger Pack > wrote: >> >> I wonder if it would be possible to integrate libevent's own asynch >> DNS library in rev somehow. > > That might be a bit difficult considering that Rev uses libev's native API > without libevent compat. Are you having problems with Rev's pure Ruby async > DNS? > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk > > From tony at medioh.com Tue Aug 12 16:05:02 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 12 Aug 2008 14:05:02 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> Message-ID: On Tue, Aug 12, 2008 at 1:43 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > Oh for some reason I thought it was using libevent not libev. > I have no idea what the status of libev is for windows. I do hope > it's something better than using select, since I think we're bound to > 64 ports max on select, since we use the old msvcrt lib or something. > Even resetting FD_SETSIZE didn't help last time I tried it. > Yes, there are relatively few solutions to multiplexing more than 64 file descriptors on Windows, and even fewer which allow you to write portable applications. This is due to a 64 event object limitation in WSAWaitForMultipleEvents() function which was imposed in early versions of Windows NT. For whatever reason, Microsoft never decided to increase this limit. Microsoft's intended solution is for you to use I/O completion ports in conjunction with thread pools. This is a nicely scalable solution but not one which maps very well to paradigms on other platforms. Solaris's event completion ports are perhaps the closest match but there's still a bit of a mismatch. So all that said, the best solution is to use thread pools which multiplex up to 64 descriptors each. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Tue Aug 12 16:53:40 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Tue, 12 Aug 2008 14:53:40 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> Message-ID: <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> I haven't looked into this too much, but here are a few thoughts: I've heard some random rumors that if you increase the FD_SETSIZE that windows is able to use it. Except that I actually tried that on mingw and it didn't work. So I guess your suggestion of multiple threads is about the only way to handle select. It's apparently possible to emulate asynchronous calls using IOCP[3]. When I google for 'libev iocp' I get something that looks like a feature request, with no news of it actually working. libevent does compile out of the box, but the test programs don't seem to output anything, so I'm a little wary to say it works. one can download the libev doesn't seem to compile. If I ever get around to it on windows I may try to see if I can hook up libevent instead of libev. Maybe it will work without threading. I can hope :) Also it appears possible to run the libevent http server using libev[1] so... it could happen :) Looks like Ry was bulding something similar[2]. Not that I plan on ever doing it, but it's just thought fodder. Take care. -R [1] http://dist.schmorp.de/libev/README.how_to_choose_between_libevent_and_libev_tarballs [2] http://lists.schmorp.de/pipermail/libev/2008q3/000406.html [3] http://www.eggheadcafe.com/software/aspnet/32292639/integrate-windows-io-com.aspx On Tue, Aug 12, 2008 at 2:05 PM, Tony Arcieri wrote: > On Tue, Aug 12, 2008 at 1:43 PM, Roger Pack > wrote: >> >> Oh for some reason I thought it was using libevent not libev. >> I have no idea what the status of libev is for windows. I do hope >> it's something better than using select, since I think we're bound to >> 64 ports max on select, since we use the old msvcrt lib or something. >> Even resetting FD_SETSIZE didn't help last time I tried it. > > Yes, there are relatively few solutions to multiplexing more than 64 file > descriptors on Windows, and even fewer which allow you to write portable > applications. This is due to a 64 event object limitation in > WSAWaitForMultipleEvents() function which was imposed in early versions of > Windows NT. For whatever reason, Microsoft never decided to increase this > limit. > > Microsoft's intended solution is for you to use I/O completion ports in > conjunction with thread pools. This is a nicely scalable solution but not > one which maps very well to paradigms on other platforms. Solaris's event > completion ports are perhaps the closest match but there's still a bit of a > mismatch. > > So all that said, the best solution is to use thread pools which multiplex > up to 64 descriptors each. > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk > > From tony at medioh.com Tue Aug 12 16:57:49 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 12 Aug 2008 14:57:49 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> Message-ID: On Tue, Aug 12, 2008 at 2:53 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > I've heard some random rumors that if you increase the FD_SETSIZE that > windows is able to use it. Nope, the 64 object limitation is an inherent limit of the Win32 API and cannot be circumvented. > It's apparently possible to emulate asynchronous calls using IOCP[3]. > It's possible to do something similar to POSIX async I/O, if you'd like high performance async file I/O. It wouldn't really be applicable to network sockets if that's your primary use case. I've talked to the libev author about this, who wrote a library called libeio for this purpose, and he thought the semantics between POSIX async I/O and IOCP were too different to really have a clean cross-platform abstraction. > If I ever get around to it on windows I may try to see if I can hook > up libevent instead of libev. Have you tried to build Rev on Windows? If you're interested in getting it working I'd certainly help out in trying to get it working, although I don't have a Windows machine to do any testing on myself. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Tue Aug 12 17:25:18 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Tue, 12 Aug 2008 15:25:18 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> Message-ID: <966599840808121425t70afb853yed303a268dfd5224@mail.gmail.com> > Nope, the 64 object limitation is an inherent limit of the Win32 API and > cannot be circumvented. Rumors exist [1] :) >> It's apparently possible to emulate asynchronous calls using IOCP[3]. I think what I meant is emulate "event-driven I/O." Files...no clue there. I know that IOCP are supposed to give you a way around the 64-fd limit, but I'm not sure if things' like [2] do or not. >> If I ever get around to it on windows I may try to see if I can hook >> up libevent instead of libev. > > Have you tried to build Rev on Windows? If you're interested in getting it > working I'd certainly help out in trying to get it working, although I don't > have a Windows machine to do any testing on myself. I have. Here's the output from trying to install rev [mingw with the devkit]: gem install rev gcc -I. -I. -Ic:/roger/dev/rubyinstaller_lavena/sandbox/ruby_mingw/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -g -O2 -c rev_buffer.c rev_buffer.c:630:2: warning: no newline at end of file gcc -I. -I. -Ic:/roger/dev/rubyinstaller_lavena/sandbox/ruby_mingw/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -g -O2 -c rev_ext.c In file included from rev_ext.c:10: ../libev/ev.c: In function `fd_intern': ../libev/ev.c:981: warning: passing arg 3 of `rb_w32_ioctlsocket' from incompatible pointer type In file included from ../libev/ev.c:1191, from rev_ext.c:10: ../libev/ev_select.c: In function `select_poll': ../libev/ev_select.c:137: error: `NFDBITS' undeclared (first use in this function) ../libev/ev_select.c:137: error: (Each undeclared identifier is reported only once ../libev/ev_select.c:137: error: for each function it appears in.) make: *** [rev_ext.o] Error 1 Here's the output from trying to install libev: make all-am make[1]: Entering directory `/c/roger/dev/libev-3.43' /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -O3 -c -o event.lo `test -f 'event.c' || echo './'`event.c gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -O3 -c event.c -DDLL_EXPORT -DPIC -o .l ibs/event.o In file included from event.c:51: event.h:115: warning: "struct timeval" declared inside parameter list event.h:115: warning: its scope is only this definition or declaration, which is probably not what you want event.h:126: warning: "struct timeval" declared inside parameter list event.h:128: warning: "struct timeval" declared inside parameter list event.h:132: warning: "struct timeval" declared inside parameter list event.h:139: warning: "struct timeval" declared inside parameter list event.h:141: warning: "struct timeval" declared inside parameter list event.c:71: warning: "struct timeval" declared inside parameter list event.c: In function `tv_set': event.c:73: error: dereferencing pointer to incomplete type event.c:74: error: dereferencing pointer to incomplete type event.c:74: error: dereferencing pointer to incomplete type event.c: At top level: I don't really care since I'm not developing on windows, but just doing it out of curiosity. Thanks! -=R [1] http://www.nntp.perl.org/group/perl.loop/2007/11/msg1082.html [2] http://article.gmane.org/gmane.comp.lib.libevent.user/158 other possibly useful: http://www.eggheadcafe.com/software/aspnet/32292639/integrate-windows-io-com.aspx http://code.jellycan.com/memcached/ From tony at medioh.com Tue Aug 12 20:02:25 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 12 Aug 2008 18:02:25 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: <966599840808121425t70afb853yed303a268dfd5224@mail.gmail.com> References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> <966599840808121425t70afb853yed303a268dfd5224@mail.gmail.com> Message-ID: On Tue, Aug 12, 2008 at 3:25 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > Rumors exist [1] :) > Interesting... I hadn't heard about that. If you're really interested in this, I'd suggest posting about it on the libev mailing list, although they may be doing something to that effect already. > Here's the output from trying to install rev [mingw with the devkit]: > I'll try to figure out what I need to do in order to detect / build libev on Windows in the extconf.rb and ping you when I think I've found a fix. > I don't really care since I'm not developing on windows, but just > doing it out of curiosity. Same here, however if there's a quick fix to get Rev building on Windows I'm willing to try. The libev guy has certainly put in a decent amount of effort into supporting Windows, so it shouldn't be too much work. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Wed Aug 13 13:29:54 2008 From: tony at medioh.com (Tony Arcieri) Date: Wed, 13 Aug 2008 11:29:54 -0600 Subject: [Rev-talk] flow v0.0.1 In-Reply-To: <3ae7f4480808130101s76b7aa1ap38ed1e229cc3fac@mail.gmail.com> References: <3ae7f4480808090655m6521b351i9b295d9bf1944191@mail.gmail.com> <1082F7E8-8A9C-4512-89B1-C0BACFA9E960@gmail.com> <3ae7f4480808101105i3c29c87by22146a967683a5ca@mail.gmail.com> <05131474-A1EA-4737-894E-60F5663E4469@gmail.com> <3ae7f4480808121740k3feb671ucb863024f5c681c0@mail.gmail.com> <3ae7f4480808130101s76b7aa1ap38ed1e229cc3fac@mail.gmail.com> Message-ID: On Wed, Aug 13, 2008 at 2:01 AM, ryah dahl wrote: > Okay - rev's HEAD looks much better. Glad to hear. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Aug 18 17:26:01 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 18 Aug 2008 15:26:01 -0600 Subject: [Rev-talk] Rev is now on github Message-ID: At the insistence of many, I've moved Rev's repository onto github: http://github.com/tarcieri/rev/tree/master For those of you with commit access to svn, please ping me to get access on github then grab the latest code from there. I pushed HEAD from svn, so what's on github is equivalent to the latest Subversion sources. I'm going to tag trunk in the svn repo for the last time (something like OLD_TRUNK) and throw a readme in there pointing to the github version. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Aug 18 17:48:51 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 18 Aug 2008 15:48:51 -0600 Subject: [Rev-talk] Spinning Rev::HttpClient off into its own gem Message-ID: tmm1 was asking me earlier today about using Rev's HTTP client on top of EventMachine. Rev::HttpClient got its start as the HTTP client from Zed Shaw's rfuzz library and features a high-performance Ragel-generated state machine parser. Ragel compiles the parser to C which in turn is wrapped as a Ruby C extension, much like the Mongrel parser. The client itself is also implemented as a state machine so it should be easily extensible, and among other things supports chunked encoding. Given the interest in using this client with EventMachine I think the best approach would be to unbundle it from Rev and make it available as a gem which works on either Rev or EventMachine. Would anyone be interested in this sort of thing? -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsisnero at gmail.com Tue Aug 19 14:06:58 2008 From: dsisnero at gmail.com (Dominic Sisneros) Date: Tue, 19 Aug 2008 12:06:58 -0600 Subject: [Rev-talk] Build fails on mingw ruby Message-ID: C:\Documents and Settings\dominic e sisneros\My Documents\downloads\ruby\rev>rake (in C:/Documents and Settings/dominic e sisneros/My Documents/downloads/ruby/rev) c:/Ruby18/bin/ruby extconf.rb checking for rb_thread_blocking_region()... no checking for rb_str_set_len()... no checking for sys/select.h... no checking for poll.h... no checking for sys/epoll.h... no checking for sys/event.h... no checking for port.h... no checking for openssl/ssl.h... yes checking for sysctlbyname() in sys/param.h,sys/sysctl.h... no creating Makefile make gcc -I. -I. -Ic:/Ruby18/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -g -O2 -c rev _buffer.c rev_buffer.c:630:2: warning: no newline at end of file gcc -I. -I. -Ic:/Ruby18/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -g -O2 -c rev _ext.c In file included from rev_ext.c:10: ../libev/ev.c: In function `fd_intern': ../libev/ev.c:981: warning: passing arg 3 of `rb_w32_ioctlsocket' from incompatible pointer type In file included from ../libev/ev.c:1191, from rev_ext.c:10: ../libev/ev_select.c: In function `select_poll': ../libev/ev_select.c:137: error: `NFDBITS' undeclared (first use in this function) ../libev/ev_select.c:137: error: (Each undeclared identifier is reported only once ../libev/ev_select.c:137: error: for each function it appears in.) make: *** [rev_ext.o] Error 1 rake aborted! Command failed with status (2): [make...] (See full trace by running task with --trace) From tony at medioh.com Tue Aug 19 14:32:46 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 19 Aug 2008 12:32:46 -0600 Subject: [Rev-talk] Build fails on mingw ruby In-Reply-To: References: Message-ID: On Tue, Aug 19, 2008 at 12:06 PM, Dominic Sisneros wrote: > ../libev/ev_select.c: In function `select_poll': > ../libev/ev_select.c:137: error: `NFDBITS' undeclared (first use in > this function) > ../libev/ev_select.c:137: error: (Each undeclared identifier is > reported only once > ../libev/ev_select.c:137: error: for each function it appears in.) > I found out about this just recently. There's something I need to do when building libev on Windows which I'm not right now. I'll look into it. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Thu Aug 21 02:07:24 2008 From: tony at medioh.com (Tony Arcieri) Date: Thu, 21 Aug 2008 00:07:24 -0600 Subject: [Rev-talk] [Eventmachine-talk] Spinning Rev::HttpClient off into its own gem In-Reply-To: References: Message-ID: For anyone who's interested I've begun working on this. It's up on Github: http://github.com/tarcieri/fasthttp/tree/master I'm starting by separating out the connection object from the client class. Rev::HttpClient was originally a subclass of Rev::TCPSocket. I'm changing that so it isn't a subclass of anything, but interfaces through a subclass of Rev::TCPSocket. After that I'll look at making the backends pluggable so it can run on Rev, EventMachine, or Plain Old Ruby Sockets On Tue, Aug 19, 2008 at 9:17 AM, oldmoe wrote: > Sure, would be handy > > oldmoe > eSpace.com.eg > oldmoe.blogspot.com > > On Aug 19, 5:55 pm, "Dominic Sisneros" wrote: > > Sounds like a good idea! I would be interested > > > > > > > > On Mon, Aug 18, 2008 at 3:48 PM, Tony Arcieri wrote: > > > tmm1 was asking me earlier today about using Rev's HTTP client on top > of > > > EventMachine. Rev::HttpClient got its start as the HTTP client from > Zed > > > Shaw's rfuzz library and features a high-performance Ragel-generated > state > > > machine parser. Ragel compiles the parser to C which in turn is > wrapped as > > > a Ruby C extension, much like the Mongrel parser. The client itself is > also > > > implemented as a state machine so it should be easily extensible, and > among > > > other things supports chunked encoding. > > > > > Given the interest in using this client with EventMachine I think the > best > > > approach would be to unbundle it from Rev and make it available as a > gem > > > which works on either Rev or EventMachine. Would anyone be interested > in > > > this sort of thing? > > > > > -- > > > Tony Arcieri > > > medioh.com > > > > > _______________________________________________ > > > Eventmachine-talk mailing list > > > Eventmachine-t... at rubyforge.org > > >http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-t... at rubyforge.orghttp:// > rubyforge.org/mailman/listinfo/eventmachine-talk > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk > -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Fri Aug 22 03:26:18 2008 From: tony at medioh.com (Tony Arcieri) Date: Fri, 22 Aug 2008 01:26:18 -0600 Subject: [Rev-talk] [Eventmachine-talk] Spinning Rev::HttpClient off into its own gem In-Reply-To: References: Message-ID: FastHTTP is working! Well, at least with Rev. It's pretty clear at this point some refactoring is in order, but the base functionality is there. I'd like to begin adding in EventMachine support, but it'd really be nice if there were some clean abstraction between EventMachine, Rev, and Ruby sockets I could use. I talked a little bit about this on the IRC channel... I may try to hack this together myself and see how things go. On Thu, Aug 21, 2008 at 12:07 AM, Tony Arcieri wrote: > For anyone who's interested I've begun working on this. It's up on Github: > > http://github.com/tarcieri/fasthttp/tree/master > > I'm starting by separating out the connection object from the client > class. Rev::HttpClient was originally a subclass of Rev::TCPSocket. I'm > changing that so it isn't a subclass of anything, but interfaces through a > subclass of Rev::TCPSocket. > > After that I'll look at making the backends pluggable so it can run on Rev, > EventMachine, or Plain Old Ruby Sockets > > > On Tue, Aug 19, 2008 at 9:17 AM, oldmoe wrote: > >> Sure, would be handy >> >> oldmoe >> eSpace.com.eg >> oldmoe.blogspot.com >> >> On Aug 19, 5:55 pm, "Dominic Sisneros" wrote: >> > Sounds like a good idea! I would be interested >> > >> > >> > >> > On Mon, Aug 18, 2008 at 3:48 PM, Tony Arcieri wrote: >> > > tmm1 was asking me earlier today about using Rev's HTTP client on top >> of >> > > EventMachine. Rev::HttpClient got its start as the HTTP client from >> Zed >> > > Shaw's rfuzz library and features a high-performance Ragel-generated >> state >> > > machine parser. Ragel compiles the parser to C which in turn is >> wrapped as >> > > a Ruby C extension, much like the Mongrel parser. The client itself >> is also >> > > implemented as a state machine so it should be easily extensible, and >> among >> > > other things supports chunked encoding. >> > >> > > Given the interest in using this client with EventMachine I think the >> best >> > > approach would be to unbundle it from Rev and make it available as a >> gem >> > > which works on either Rev or EventMachine. Would anyone be interested >> in >> > > this sort of thing? >> > >> > > -- >> > > Tony Arcieri >> > > medioh.com >> > >> > > _______________________________________________ >> > > Eventmachine-talk mailing list >> > > Eventmachine-t... at rubyforge.org >> > >http://rubyforge.org/mailman/listinfo/eventmachine-talk >> > >> > _______________________________________________ >> > Eventmachine-talk mailing list >> > Eventmachine-t... at rubyforge.orghttp:// >> rubyforge.org/mailman/listinfo/eventmachine-talk >> _______________________________________________ >> Eventmachine-talk mailing list >> Eventmachine-talk at rubyforge.org >> http://rubyforge.org/mailman/listinfo/eventmachine-talk >> > > > > -- > Tony Arcieri > medioh.com > -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ry at tinyclouds.org Fri Aug 22 06:56:05 2008 From: ry at tinyclouds.org (ryah dahl) Date: Fri, 22 Aug 2008 12:56:05 +0200 Subject: [Rev-talk] [Eventmachine-talk] Spinning Rev::HttpClient off into its own gem In-Reply-To: References: Message-ID: <3ae7f4480808220356m7c17ebefvc9e153d90bc497f9@mail.gmail.com> > I'd like to begin adding in EventMachine support, but it'd really be nice if > there were some clean abstraction between EventMachine, Rev, and Ruby > sockets I could use. this would be great! From lists at daesan.com Wed Aug 27 19:54:34 2008 From: lists at daesan.com (Dae San Hwang) Date: Thu, 28 Aug 2008 08:54:34 +0900 Subject: [Rev-talk] Rev::Buffer#read bug Message-ID: <43B9C97E-B0B2-45E8-856B-28D453F23EEC@daesan.com> Hi. Though length in "Rev::Buffer#read(length=nil)" is an optional argument, "Rev::Buffer.new.read(nil)" raises "TypeError: no implicit conversion from nil to integer". I fixed this at git://github.com/daesan/rev.git. Please consider merging. daesan From tony at medioh.com Thu Aug 28 13:41:13 2008 From: tony at medioh.com (Tony Arcieri) Date: Thu, 28 Aug 2008 11:41:13 -0600 Subject: [Rev-talk] Rev::Buffer#read bug In-Reply-To: <43B9C97E-B0B2-45E8-856B-28D453F23EEC@daesan.com> References: <43B9C97E-B0B2-45E8-856B-28D453F23EEC@daesan.com> Message-ID: On Wed, Aug 27, 2008 at 5:54 PM, Dae San Hwang wrote: > Hi. > > Though length in "Rev::Buffer#read(length=nil)" is an optional argument, > "Rev::Buffer.new.read(nil)" raises "TypeError: no implicit conversion from > nil to integer". > > I fixed this at git://github.com/daesan/rev.git. Please consider merging. > Thanks. I'll take a look tonight. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.pack at leadmediapartners.com Fri Aug 29 12:23:57 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Fri, 29 Aug 2008 10:23:57 -0600 Subject: [Rev-talk] dns resolution In-Reply-To: References: <966599840808121141t40f5e2f9k6276faa893914cb4@mail.gmail.com> <966599840808121243u4fffe50pece78567e6fb2aa0@mail.gmail.com> <966599840808121353h7f851f1ep4041b0cd5c10e407@mail.gmail.com> <966599840808121425t70afb853yed303a268dfd5224@mail.gmail.com> Message-ID: <966599840808290923u4ef2a8e4n58f794ed5276e7f@mail.gmail.com> > Interesting... I hadn't heard about that. If you're really interested in > this, I'd suggest posting about it on the libev mailing list, although they > may be doing something to that effect already. I wonder if compiling all of Ruby, itself, with FD_SETSIZE set to a larger number would work. I also wonder if windows works with non-blocking file handles [sockets and handles]. [this guy [1] mentioned something] -- but I guess that's an optimization for another day. I also wonder why libevent and libev don't just work together to form one project that's optimized. Seems like duplication there :) Thanks for your work. -=R [1] http://monkeymail.org/archives/libevent-users/2008-July/001343.html > >> >> Here's the output from trying to install rev [mingw with the devkit]: > > I'll try to figure out what I need to do in order to detect / build libev on > Windows in the extconf.rb and ping you when I think I've found a fix. > >> >> I don't really care since I'm not developing on windows, but just >> doing it out of curiosity. > > Same here, however if there's a quick fix to get Rev building on Windows I'm > willing to try. The libev guy has certainly put in a decent amount of > effort into supporting Windows, so it shouldn't be too much work. > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk > > -- Thanks! -=R