# Async db writes to logs **URL:** \ **Category:** Rails\ **Created:** [June 6, 2008, 8:29pm UTC](https://www.ruby-forum.com/t/async-db-writes-to-logs/139765 "2008-06-06T20:29:39Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [June 6, 2008, 8:29pm UTC](https://www.ruby-forum.com/t/async-db-writes-to-logs/139765/1 "2008-06-06T20:29:39Z")
I am looking for the most direct approach to launching ansyncronous database writes. These would be one-way, fire & forget. I can tolerate the occasional lost message. Been doing a bunch of reading on async process for Rails. I see several “process schedulers” that have been written such as BackgroundJob, AP4R, etc. (saw the thread re: forking/threading). I’m fairly certain I don’t want these types of systems. I don’t need a “scheduler,” I just want to send some writes to a separate database during the course of processing a Rails request and not have the Rails processes held up by those connections. In my previous work with Lasso, all that was needed for that was adding an -async option to a method, and voila, a completely independent and async thread was launched for that code that took advantage of additional CPUs, etc. From what I gather about Ruby, I think all I want to do is use Thread.new with a raw mysql-ruby connection (don’t need ActiveRecord for this) in the block. Does that sound about right? And, just for curiousity sake, it would appear that launching a new Thread in Ruby would actually remain tied to the same CPU core? This is the “family secret” about threads that one reads about Ruby? So conceivably if the main thread or the new thread were intense enough, launching a new thread wouldn’t actually provide any practical concurrent gains? I know that I most cases gains are probably made, just asking if that’s the talking point some people have against Ruby & threading. – def gw acts\_as\_padawan writes\_at ‘www.railsdev.ws’ end ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [June 7, 2008, 8:14pm UTC](https://www.ruby-forum.com/t/async-db-writes-to-logs/139765/2 "2008-06-07T20:14:58Z")
On 6 Jun 2008, at 19:28, Greg W. wrote: > And, just for curiousity sake, it would appear that launching a new > Thread in Ruby would actually remain tied to the same CPU core? This > is the “family secret” about threads that one reads about Ruby? MRI’s threads are so called green threads - they exist entirely within the interpreter, from the point of the OS there is only ever a single thread (and so only one ruby thread actually ever runs at once). This approach to threading also means a single ruby thread can block the entire ruby vm. This won’t happen with pure ruby code, since ruby’s scheduler takes care of that but can happen with c extensions (so to give the simplest example, a c extension that just calls sleep(5) will block all ruby threads for 5 seconds). So if (for example) the c interface to mysql were to be blocking then a mysql query would block the app, threads or no threads. Unfortunately that is the case. The pure ruby mysql doesn’t suffer from that problem, however it’s not recommended for production use (and you can’t mix and match them inside a single ruby process. It’s also the case that jruby gives you ‘real’ threads. Fred ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [June 7, 2008, 9:14pm UTC](https://www.ruby-forum.com/t/async-db-writes-to-logs/139765/3 "2008-06-07T21:14:31Z")
On Jun 7, 7:44 pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Jun 7, 2008, at 11:14 AM, Frederick C. wrote: > Thanks for the description. > > So Thread.new might allow Ruby to work on two pure Ruby workloads > concurrently (two big iterates or something), but the scenario I was > after is pretty much just going to be linear anyway? Bummer. Unfortunately, yes Fred ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [June 7, 2008, 8:45pm UTC](https://www.ruby-forum.com/t/async-db-writes-to-logs/139765/4 "2008-06-07T20:45:03Z")
On Jun 7, 2008, at 11:14 AM, Frederick C. wrote: > the interpreter, from the point of the OS there is only ever a single > recommended for production use (and you can’t mix and match them > inside a single ruby process. > It’s also the case that jruby gives you ‘real’ threads. Thanks for the description. So Thread.new might allow Ruby to work on two pure Ruby workloads concurrently (two big iterates or something), but the scenario I was after is pretty much just going to be linear anyway? Bummer. – def gw writes\_at ‘www.railsdev.ws’ end