tag:blogger.com,1999:blog-15616477.post6224774362620258664..comments2023-10-22T11:49:21.348+03:00Comments on oldmoe: NeverBlock, much faster IO for Rubyoldmoehttp://www.blogger.com/profile/14341721253106429644noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-15616477.post-2216884366656764762008-08-23T23:37:00.000+03:002008-08-23T23:37:00.000+03:00I have a working AR implementation now. Only final...I have a working AR implementation now. Only finalizing a few rough edges. I didn't like playing with Thread.current[] so I just replaced the AR methods I needed (mainly in Transaction). The good news is that it is a one line change for AR users.<BR/><BR/>Rails is just around the corner, but I am still tying things together and doing tests. But I am glad that Rails is (mostly) working with Ruby1.9<BR/><BR/>Regarding sending queries and ignoring the response this is surely a plus for things like logging. I believe it would be very easy to implement. I am using Fiber.current[] as the communication channel now. <BR/><BR/>I like your advertising idea, this would definitely attract attention. I will work on that and see what I can come up with.<BR/><BR/>Again, thanks for offering help, I more than willing to accept the offer :)oldmoehttps://www.blogger.com/profile/14341721253106429644noreply@blogger.comtag:blogger.com,1999:blog-15616477.post-45028384236256380762008-08-23T21:55:00.000+03:002008-08-23T21:55:00.000+03:00Yeah the GC stinks. You can decrease the GC impact...Yeah the GC stinks. You can decrease the GC impact by [in my case] about half if you apply skae's gcpatch [but that requires recompiling Ruby...heh]. If somebody wants to team with me it would be fun to build generational or threaded GC.<BR/><BR/>Some thoughts on neverblock:<BR/>If you do fork you will probably want ruby enterprise edition to cut back on wasted RAM. There's also optionally multi-threaded as mentioned earlier.<BR/><BR/>I also wonder if an option to 'not wait for a query to complete before continuing execution' would be useful. Ex: updates and inserts where you don't plan on using that information in the near future [since inserts tend to take quite a bit longer than queries]. Maybe useful :) Or, expanding on that, queries which can be performed 'on idle' or later, whenever you have some free CPU or what not. Possibly useful. Just some thoughts.<BR/><BR/>Also re: advertising. <BR/>If you can advertise neverblock as "an instant scaling dropin for rails 2.2" I think that would perk people's attention to it.<BR/><BR/>In order to get it to work you'd have to rewrite Thread.current[] to access the current fiber, I guess, and also link ActiveRecord to use neverblock and use a fibered driver [fibered mongrel or what not]. Something like that. I'm not sure of all the intricacies, but that's what might be most community useful.<BR/><BR/>Let me know how I can help.<BR/>Take care.<BR/>-=R<BR/><BR/>note: gcpatch: http://github.com/skaes/railsbench/tree/master/GCPATCHAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15616477.post-13215901957537419682008-08-21T17:29:00.000+03:002008-08-21T17:29:00.000+03:00Yeah this is similar but a little more hard-core t...Yeah this is similar but a little more hard-core than revactor. <BR/>I think the only thing asymy lacks [besides the bugs you pointed out] is error reporting--like if you do a query and the connection has already been dropped or what not.<BR/>One possibility would be to change the syntax from:<BR/><BR/>EventMachine::run {<BR/> c = Asymy::Connection.new(:target => "localhost",<BR/> :port => 13306,<BR/> :username => "user",<BR/> :password => "pass",<BR/> :database => "mysql")<BR/> c.exec("show databases") do |fields, rows|<BR/> pp fields<BR/> pp rows<BR/> end<BR/>}<BR/><BR/>to<BR/><BR/> c.exec("show databases") do |fields, rows, error_message|<BR/> end<BR/><BR/>Feel free to provide patches to the author--I think he accepts them :)Roger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.comtag:blogger.com,1999:blog-15616477.post-86621660256483688842008-08-21T00:07:00.000+03:002008-08-21T00:07:00.000+03:00The road map for NeverBlock includes providing rep...The road map for NeverBlock includes providing replacements for stuff like Net::HTTP, utilizing Tony's async ruby socket replacements' code.<BR/><BR/>The garbage collector with its shameful pause is a real issue. Would love to see a generational one some day.<BR/><BR/>Anyway, if you monopolize cpu time with too many calculations then you will block the event loop anyway, that is why I am thinking of forked worker processesoldmoehttps://www.blogger.com/profile/14341721253106429644noreply@blogger.comtag:blogger.com,1999:blog-15616477.post-6513196111521209482008-08-20T20:11:00.000+03:002008-08-20T20:11:00.000+03:00Looks nice.The only thing I can think of that woul...Looks nice.<BR/>The only thing I can think of that would block would be the garbage collector [oh, and if anybody uses Net::HTTP within a controller or what not, or mechanize, etc.]<BR/><BR/>I did some teeny bit of work on making the garbage collector multi-threaded recently [and thus non-blocking]. Perhaps someday the project will present itself if I get around to it [1]. Non-blocking is definitely better, I'd agree. I like the potential this has. It might double the total processing speed, or perhaps even more.<BR/>Congrats.<BR/>-=R<BR/><BR/>[1] mentioned in here somewhere http://www.ruby-forum.com/topic/128068#newRoger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.com