From rogerpack2005 at gmail.com Tue Jun 3 14:59:39 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Tue, 3 Jun 2008 12:59:39 -0600 Subject: [Rev-talk] java Message-ID: <966599840806031159x414f733exb5223cf94e71298@mail.gmail.com> I assume there is no jruby implementation? :) -R From tony at medioh.com Tue Jun 3 16:34:31 2008 From: tony at medioh.com (Tony Arcieri) Date: Tue, 3 Jun 2008 14:34:31 -0600 Subject: [Rev-talk] java In-Reply-To: <966599840806031159x414f733exb5223cf94e71298@mail.gmail.com> References: <966599840806031159x414f733exb5223cf94e71298@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 12:59 PM, Roger Pack wrote: > I assume there is no jruby implementation? :) > Nope, sorry. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Wed Jun 11 16:34:45 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Wed, 11 Jun 2008 14:34:45 -0600 Subject: [Rev-talk] fibers fast? In-Reply-To: References: <966599840806111253m448d26dpb60606c7be8b2d9d@mail.gmail.com> Message-ID: > Revactor already provides the glue for using Fibers on top of Rev, > and also bundles a version of Mongrel which uses Actors/Fibers for > concurrency instead of threads. Nice. Thanks for doing that! So it's a single threaded mongrel, like the evented version? I assume all the fibers still block in DB calls? This being the case then perhaps ramaze/merb + sequel using an evented database would yield a non IO-blocking, single threaded server? > > Just install Revactor and require 'revactor/mongrel' > > using fibers > > def action_1 # this is run within a fiber > @schools = DB.run 'select * from schools' # the fiber yields until > the DB call comes back, then it resumes > @locations = @schools[0] # same as above > render > end > > Yes, you could definitely do something like that with Revactor, > particularly since it already handles scheduling fibers based on I/O > events, and provides a routine for you to call to suspend the > current Fiber until an I/O event occurs. Nice. > > > Questions: > Do you think would fibers be 'significantly slower'? > > It's been fast for me. According to my benchmarks I'm able to task > switch between 50,000 fibers per second with Revactor acting as the > scheduler, so that includes message processing, matching, and > dispatch. creation speed is trivial, I'd guess, too? If I got into it too much I wonder if file descriptor support for reading/writing would be nice :) [or if it typically would be useless since you can read them pretty fast). > > Does an evented DB driver in Ruby stand a chance speed-wise to the > 'real' C versions? I guess it would be possible to write one in C to > complement rev, but that would be a future optimization. > My goal really is speed. Trying to go for unbelievable speed, here :) > > I think on Rubinius or MagLev they certainly would, but both of > these likely mitigate the need for an evented driver in the first > place as they're fundamentally "evented" at the scheduler level > (e.g. Rubinius uses libev for its scheduler) I suppose that's if the interpreter were lightning fast. Which I guess could be the case sometime once maglev gets released or rubinius gets their act together. > That said on MRI/YARV I'd expect database interaction done in Ruby > to be slower than the C counterparts. However it might be possible > to coerce evented behavior out of the C libraries... I'd have to > check the APIs. A quick google search reveals that asynchronous mysql clients seem pretty rare :) Perhaps a ruby version [like that noted in the EM list recently] is a nice first shot at it though. Thanks for the speedy response! -R From rogerpack2005 at gmail.com Wed Jun 11 17:29:17 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Wed, 11 Jun 2008 15:29:17 -0600 Subject: [Rev-talk] fibers fast? In-Reply-To: References: <966599840806111253m448d26dpb60606c7be8b2d9d@mail.gmail.com>

Message-ID: <966599840806111429i531e3c5fm461797db4a63a98c@mail.gmail.com> What's your take on continuations versus fibers? I assume fibers are faster, but they'd both work for a server style architecture? [Also my previous wish list item was that we could also not block on file i/o, but that's probably more an optimization for later]. Thanks! -R From tony at medioh.com Sun Jun 29 17:57:33 2008 From: tony at medioh.com (Tony Arcieri) Date: Sun, 29 Jun 2008 15:57:33 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281422n5d1f9c00o525c8a2365c0dd7a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> Message-ID: On Sat, Jun 28, 2008 at 5:44 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote: > Also within the run function, should it set @running to false at the > end of the function? > Yes, and a Rev::Loop#running? method should probably be added. > Also do you want me to write these to rev talk? > Yes, too bad I didn't see this until now... good idea! I already responded to your other messages separately, but if you can cross-post your replies to rev-talk that'd be great. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Mon Jun 30 12:17:43 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 10:17:43 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281422n5d1f9c00o525c8a2365c0dd7a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> Message-ID: <0171007F-C24E-4581-AC20-00F19CE63484@gmail.com> On Jun 29, 2008, at 3:57 PM, Tony Arcieri wrote: > On Sat, Jun 28, 2008 at 5:44 PM, Roger Pack > wrote: > Also within the run function, should it set @running to false at the > end of the function? > > Yes, and a Rev::Loop#running? method should probably be added. > > Also do you want me to write these to rev talk? Should I handle it? Also I think what might be really ideal for helping it with interoperability with other ruby threads would be a run that just blocks up to a certain time. Kind of like the timeout value passed to select. so something like loop.run_once_until s #seconds Then you could have every s seconds control [possibly] pass back to other running ruby threads. Otherwise with 1.8.6 it's either loop using 100% CPU and run_once, or loop_once, sleep, and repeat -- somewhat non ideal. The only reason I even care is that I was writing some specs and wanted to write a test where it closes asynchronously [faking an incoming connection that causes it to close]. And realized the difficulty. Thanks! -R > > Yes, too bad I didn't see this until now... good idea! I already > responded to your other messages separately, but if you can cross- > post your replies to rev-talk that'd be great. > > -- > Tony Arcieri > medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Jun 30 13:30:03 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 30 Jun 2008 11:30:03 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281422n5d1f9c00o525c8a2365c0dd7a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> Message-ID: On Mon, Jun 30, 2008 at 10:17 AM, Roger Pack wrote: > Should I handle it? > Go for it. > Also I think what might be really ideal for helping it with > interoperability with other ruby threads would be a run that just blocks up > to a certain time. Kind of like the timeout value passed to select. > so something like loop.run_once_until s #seconds > Rev already runs Ruby threads explicitly every 10ms while the event loop is running with rb_thread_schedule(). > The only reason I even care is that I was writing some specs and wanted to > write a test where it closes asynchronously [faking an incoming connection > that causes it to close]. And realized the difficulty. > This test should work as things are, hopefully. > Ah I see--so it's pretty good as it is now. So on_connect_failed is like a > hard reset? and on_close a graceful 'soft' reset? > on_connect_failed is called when you're making an outgoing connection that never completes. on_close is called once that connection has been established and terminates. Also I don't actually use this but does rev offer us a connect timeout? > There's no built-in connect timeout at the moment. It'd be fairly easy to add with a TimerWatcher. > What about a timeout if a socket hasn't written or read for a long time? > [i.e. EM's heartbeats--which aren't even turned on by default, and I don't > use then, but hey, just wondering]. > Nope. Actually all this stuff is built into Revactor, just not Rev :/ Also I'm still unsure why rev would be necessarily slower than EM. Except > that it returns to Ruby once per loop [of necessity in 1.8.6, for > multi-threaded]. > It depends on the usage pattern. When I was running ruby-prof on Thin on Rev the biggest problem I noticed was the Rev::Watcher#detach method. Right now this is O(n) for n concurrent connections, as it's using a simple array to track watchers. Switching to a hash would improve behavior. It'd also be possible to make it O(n) by using a "bag" like data structure where the order of the descriptors isn't preserved. Beyond that, it was just the totality of rb_funcalls needed to process incoming I/O events. One potential optimization is to do a "proactor" IOWatcher in C which performs the I/O for you whenever the descriptor is ready. > I'm not sure of the bottleneck, or difference, if there is one, but if it's > preserving object for GC marking, I wonder if it's possible to write A ruby > object that has its own GC mark function so that it can safely mark all > current active watchers. > That's what Rev::Loop is presently doing. The only reason it *needs* to track associated watchers is so they don't get GC'd. Making the way this works more efficient would improve Rev's performance. So this 'redefines' on_write_complete to call close? Nice. The only > reason I can think of to have a close_after_write function would be if > close_after_write is already defined with useful code that you don't want to > overwrite. > Yep, that'd be a downside, but AFAIK EM got away with not even having an on_write_complete callback, so I think its potential use cases are limited. I'm using in in Revactor to emulate "blocking" write calls. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Mon Jun 30 14:05:14 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 12:05:14 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281422n5d1f9c00o525c8a2365c0dd7a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> Message-ID: <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> I guess my confusion was why this spec fails: it "should stop" do loop = Rev::Loop.default stopped = false; @server.attach(loop) Thread.new { loop.run stopped = true } sleep 0 # let it start stopped.should == false loop.stop sleep_until(3) { stopped == true } stopped.should == true end I take it that it never 'returns to ruby' from its run_once unless it actually processes something? Thanks! -R On Mon, Jun 30, 2008 at 11:55 AM, Roger Pack wrote: >> >> Ah I see--so it's pretty good as it is now. So on_connect_failed is like >> a hard reset? and on_close a graceful 'soft' reset? >> >> on_connect_failed is called when you're making an outgoing connection that >> never completes. on_close is called once that connection has been >> established and terminates. > > never completes meaning "hard reset"? [TCP reset message usually sent when > you contact a port that's closed--whatever TCP calls it I can't remember] > > So there is some ambiguity in the reason for on_close still? It could be > terminated by TCP RESET or by a graceful terminate? Or EPIPE or what not? > [Not that it really matters--and it's already better than EM's ambiguous > unbind]. > >> then, but hey, just wondering]. >> I'm not sure of the bottleneck, or difference, if there is one, but if >> it's preserving object for GC marking, I wonder if it's possible to write A >> ruby object that has its own GC mark function so that it can safely mark all >> current active watchers. >> >> That's what Rev::Loop is presently doing. The only reason it *needs* to >> track associated watchers is so they don't get GC'd. Making the way this >> works more efficient would improve Rev's performance. > > You could defined a custom gc_mark function that marks your active watchers > during mark and sweep. But if it works currently then why fix what ain't > broke :) > > Wonder if EM runs into GC problems. > >> Switching to a hash would improve behavior. It'd also be possible to make >> it O(n) by using a "bag" like data structure where the o >> rder of the descriptors isn't preserved. > > but still O(n), so no huge improvement? > > Also am thinking of starting some FAQ or other. Should I just put it in the > README at the bottom or something? Creating it is easy--putting it > somewhere where it can hopefully stay up to date and actually get used by > people--that is something different. Accessibility. It probably won't be > much just answers to my own questions. > > Thanks! > > -R > From tony at medioh.com Mon Jun 30 14:31:49 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 30 Jun 2008 12:31:49 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> Message-ID: On Mon, Jun 30, 2008 at 12:05 PM, Roger Pack wrote: > I guess my confusion was why this spec fails: > Right now Rev::Loop#stop isn't thread-safe. > I take it that it never 'returns to ruby' from its run_once unless it > actually processes something? > Yeah, the actual check that will stop the loop isn't performed until events are actually dispatched. So if there aren't any events dispatched, the loop won't stop. Making this work would require some changes to the C code, and mutexes around the @running ivar. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Mon Jun 30 15:08:55 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 13:08:55 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281644u62130cebp7228d22d5c14b15@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> Message-ID: <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> On Jun 30, 2008, at 12:31 PM, Tony Arcieri wrote: > On Mon, Jun 30, 2008 at 12:05 PM, Roger Pack > wrote: > I guess my confusion was why this spec fails: > > Right now Rev::Loop#stop isn't thread-safe. > > I take it that it never 'returns to ruby' from its run_once unless it > actually processes something? > > Yeah, the actual check that will stop the loop isn't performed until > events are actually dispatched. So if there aren't any events > dispatched, the loop won't stop. > > Making this work would require some changes to the C code, and > mutexes around the @running ivar. Hopefully the C code stuff would be enough :) I guess EM could run into the same type of thing [something in the reactor could call stop, while some other thread calls stop, and EM stops and restarts before the other thread calls stop--or something pathological like that] but it doesn't seem to be a big problem. Another way would be to push the @running var into the C code. Since Ruby will only be running one thread at a time, a function that sets it in C is like atomic. The way rev currently runs currently [not going back to ruby unless necessary] is probably far faster cpu-wise, and if I need instant stop access, I could always add a loop break reader. Anyway it's not too high prio, just confusing. I'll make a note of it in the faq :) I can see that rev is more of a core eventer, not as fleshed out as EM or revactor. But hopefully with fewer bugs [ugh]. I almost wonder if that rb_thread_schedule call makes it less efficient if it's single threaded--I assume not? Also I assume that in Ruby 1.9 the global lock is release during the select calls so that it can be true multi-threaded? [at least I think that's how it [should] work--does that make sense?] -R -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Jun 30 15:19:25 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 30 Jun 2008 13:19:25 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> Message-ID: On Mon, Jun 30, 2008 at 1:08 PM, Roger Pack wrote: > Another way would be to push the @running var into the C code. Since Ruby > will only be running one thread at a time, a function that sets it in C is > like atomic. > Except Ruby 1.9 uses multiple threads, so it'd still need a mutex in C code for that case. Also, it'd need to "wake up" the thread making the blocking call, as it'd be sleeping in a system call. > The way rev currently runs currently [not going back to ruby unless > necessary] is probably far faster cpu-wise, and if I need instant stop > access, I could always add a loop break reader. > There's an AsyncWatcher type which allows you to signal a loop and wake it up. That's how a stop function would probably have to be implemented: http://rev.rubyforge.org/rdoc/classes/Rev/AsyncWatcher.html > I can see that rev is more of a core eventer, not as fleshed out as EM or > revactor. But hopefully with fewer bugs [ugh]. > Yeah, right now Rev isn't the everything-and-the-kitchen-sink type framework EventMachine is. There's certainly bugs, but as the majority of the code is in Ruby instead of C/C++ they should be easier to locate and fix. > I almost wonder if that rb_thread_schedule call makes it less efficient if > it's single threaded--I assume not? > It does slow things down, although right now that's nowhere close to the main performance bottleneck. For high performance on Ruby 1.8 Rev would really need to take over the duties of rb_thread_schedule(). This would allow it to make system calls that block indefinitely in the event no threads are runnable. > Also I assume that in Ruby 1.9 the global lock is release during the select > calls so that it can be true multi-threaded? > Yep, on Ruby 1.9 Rev uses the rb_thread_blocking_region() function to make syscalls that block indefinitely. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Mon Jun 30 15:27:48 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 13:27:48 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <966599840806281656i577a6e92s945ca079a71ecb06@mail.gmail.com> <966599840806282059w1c9599e9hdb82aa4cd34f5289@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> Message-ID: <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> On Jun 30, 2008, at 1:19 PM, Tony Arcieri wrote: > On Mon, Jun 30, 2008 at 1:08 PM, Roger Pack > wrote: > Another way would be to push the @running var into the C code. > Since Ruby will only be running one thread at a time, a function > that sets it in C is like atomic. > > Except Ruby 1.9 uses multiple threads, so it'd still need a mutex in > C code for that case. Also, it'd need to "wake up" the thread > making the blocking call, as it'd be sleeping in a system call. Ahh so in 1.9 does it select for longer? Or is it either a loopbreak reader or wait 10ms? :) If @running is within a region bounded by the global thread lock would it be like 'atomic'? > > > The way rev currently runs currently [not going back to ruby unless > necessary] is probably far faster cpu-wise, and if I need instant > stop access, I could always add a loop break reader. > > There's an AsyncWatcher type which allows you to signal a loop and > wake it up. That's how a stop function would probably have to be > implemented: > > http://rev.rubyforge.org/rdoc/classes/Rev/AsyncWatcher.html I see so asynchwatcher is essentially a loop break reader. I wonder if you can actually send it an empty packet for its 'touch' :) > > I can see that rev is more of a core eventer, not as fleshed out as > EM or revactor. But hopefully with fewer bugs [ugh]. > > Yeah, right now Rev isn't the everything-and-the-kitchen-sink type > framework EventMachine is. There's certainly bugs, but as the > majority of the code is in Ruby instead of C/C++ they should be > easier to locate and fix. > > I almost wonder if that rb_thread_schedule call makes it less > efficient if it's single threaded--I assume not? > > It does slow things down, although right now that's nowhere close to > the main performance bottleneck. For high performance on Ruby 1.8 > Rev would really need to take over the duties of > rb_thread_schedule(). This would allow it to make system calls that > block indefinitely in the event no threads are runnable. Yeah going after bottlenecks is probably a better idea than fine tuning. Lol. > > Also I assume that in Ruby 1.9 the global lock is release during the > select calls so that it can be true multi-threaded? > > Yep, on Ruby 1.9 Rev uses the rb_thread_blocking_region() function > to make syscalls that block indefinitely. so not 10ms? Thanks! -R -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at medioh.com Mon Jun 30 15:40:17 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 30 Jun 2008 13:40:17 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> Message-ID: On Mon, Jun 30, 2008 at 1:27 PM, Roger Pack wrote: > Ahh so in 1.9 does it select for longer? Or is it either a loopbreak > reader or wait 10ms? :) > With Ruby 1.9 it can block idefinitely, so there's nothing breaking the loop to scheduler Ruby threads. It just sits and blocks until one of the descriptors becomes ready. Much more efficient than 1.8, to the point that Rev was originally outperforming EventMachine on 1.9 (but that was before EM started using rb_thread_blocking_region too) so not 10ms? > The 10ms thing is only on Ruby 1.8. > If @running is within a region bounded by the global thread lock would it > be like 'atomic'? > Hard to say, you could probably depend on the GVL to be a mutex for it in 1.9, but not in 1.8. It seems to me like the best approach is to wrap it in a Mutex and be done with it. > I see so asynchwatcher is essentially a loop break reader. > Yep, AsyncWatcher is designed to let one thread (be it a 1.8 green thread or a 1.9 native thread) wake up another one and execute the specified callback. > I wonder if you can actually send it an empty packet for its 'touch' :) > Not really sure what you mean... -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerpack2005 at gmail.com Mon Jun 30 15:44:37 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 13:44:37 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> Message-ID: <00A3AB0D-5823-44DD-AC6C-46C6E2A58251@gmail.com> > Yep, AsyncWatcher is designed to let one thread (be it a 1.8 green > thread or a 1.9 native thread) wake up another one and execute the > specified callback. > > I wonder if you can actually send it an empty packet for its > 'touch' :) > > Not really sure what you mean... Currently it runs its loopbreaker by sending "\0" -- I was just tongue in cheek wondering if it could send "" :) -R From rogerpack2005 at gmail.com Mon Jun 30 16:25:22 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 30 Jun 2008 14:25:22 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <8B620230-D70A-4C0F-9131-F1073F1E62BA@gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> Message-ID: <966599840806301325m63520f82saea052aa6f50b8d@mail.gmail.com> Tony Arcieri wrote: > On Mon, Jun 30, 2008 at 1:27 PM, Roger Pack wrote: >> >> Ahh so in 1.9 does it select for longer? Or is it either a loopbreak >> reader or wait 10ms? :) > > With Ruby 1.9 it can block idefinitely, so there's nothing breaking the loop > to scheduler Ruby threads. It just sits and blocks until one of the > descriptors becomes ready. Nice. Way to be efficient :) The only reason I can think of for NOT wanting to block indefinitely [in EM's case] is to check if connect timeouts have occurred, or 'idle timeouts' [heartbeats]. I don't even use those, and they're easily configurable with watchers. From tony at medioh.com Mon Jun 30 16:29:53 2008 From: tony at medioh.com (Tony Arcieri) Date: Mon, 30 Jun 2008 14:29:53 -0600 Subject: [Rev-talk] patches for rev In-Reply-To: <966599840806301325m63520f82saea052aa6f50b8d@mail.gmail.com> References: <966599840806281118h4ffb23b6l75476abaf3b4f45a@mail.gmail.com> <1C08DB9E-84DE-424C-9EF2-534B2E85AEA0@gmail.com> <966599840806301105i4de363dfi23e4adaca07bd3c1@mail.gmail.com> <0172DD11-341A-4FB6-AB8E-656D05A0E4D2@gmail.com> <6049978E-5A26-4034-BA42-B1A071777826@gmail.com> <966599840806301325m63520f82saea052aa6f50b8d@mail.gmail.com> Message-ID: On Mon, Jun 30, 2008 at 2:25 PM, Roger Pack wrote: > Nice. Way to be efficient :) > The only reason I can think of for NOT wanting to block indefinitely > [in EM's case] is to check if connect timeouts have occurred, or 'idle > timeouts' [heartbeats]. I don't even use those, and they're easily > configurable with watchers. > Yep, TimerWatchers let you break out of the loop at configurable intervals, and can be used to implement connection timeouts. There's other watchers that libev implements but Rev does not presently wrap as well, like ev_stat watchers that can be used to monitor filesystem events. Seems useful for things like autotest that monitor the filesystem for changes. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: