3 ms·

Fantastic. Instead of facing up to the crippling inadequacies of Ruby's single threaded implementation, we get a mad scientist solution. I swear Ruby attracts

by cosmo7 18y ago

Fantastic. Instead of facing up to the crippling inadequacies of Ruby's single threaded implementation, we get a mad scientist solution. I swear Ruby attracts bad thinking like a magnet.

igrigorik 18y ago
I don't think that's the case at all. The problem is exactly the same in any language - which is why we've seen a multitude of Java / Perl / Python / Ruby / C drivers developed to do the exact same thing. As someone has already pointed out, it's not about the threading, it's about turning a blocking request, into an asynchronous one. (Deferring work until you have the data to perform meaningful actions with it).
- neilc 18y ago
  I think the reason this is a bad idea is that in order to turn a blocking operation into an async one, you're adding a totally new transport layer (HTTP) and data representation (JSON), as well as middleware. That means a significant performance hit, and a lot of needless complexity (and potential for failure). It would be much simpler to either make the database driver itself non-blocking (Postgres' client library supports async queries, for instance), or use a dedicated pool of threads to perform blocking DB operations. It might be that Ruby's threading is too broken for the latter to be feasible, but it still makes using DBSlayer just to get async DB operations needless overkill.
tptacek 18y ago
I actually tend to agree; Ruby's equivalent to Python's "Twisted" is EventMachine --- a respectable event loop library --- and there is a pernicious meme there that one of the things we should be doing with the event loop is yet-another-nonpreemptive-thread-scheduler. There's nothing wrong with an app stack that is async up through the database client. Async is good. There are things that are wrong with app stacks that are entirely threaded, but we can have that argument somewhere else. But there is something wrong with the idea that we can have the best of both worlds, if we just try to make async code look like threaded code.

by cosmo7 18y ago

Fantastic. Instead of facing up to the crippling inadequacies of Ruby's single threaded implementation, we get a mad scientist solution. I swear Ruby attracts bad thinking like a magnet.

igrigorik 18y ago

I don't think that's the case at all. The problem is exactly the same in any language - which is why we've seen a multitude of Java / Perl / Python / Ruby / C drivers developed to do the exact same thing. As someone has already pointed out, it's not about the threading, it's about turning a blocking request, into an asynchronous one. (Deferring work until you have the data to perform meaningful actions with it).

neilc 18y ago
I think the reason this is a bad idea is that in order to turn a blocking operation into an async one, you're adding a totally new transport layer (HTTP) and data representation (JSON), as well as middleware. That means a significant performance hit, and a lot of needless complexity (and potential for failure). It would be much simpler to either make the database driver itself non-blocking (Postgres' client library supports async queries, for instance), or use a dedicated pool of threads to perform blocking DB operations. It might be that Ruby's threading is too broken for the latter to be feasible, but it still makes using DBSlayer just to get async DB operations needless overkill.

tptacek 18y ago

I actually tend to agree; Ruby's equivalent to Python's "Twisted" is EventMachine --- a respectable event loop library --- and there is a pernicious meme there that one of the things we should be doing with the event loop is yet-another-nonpreemptive-thread-scheduler. There's nothing wrong with an app stack that is async up through the database client. Async is good. There are things that are wrong with app stacks that are entirely threaded, but we can have that argument somewhere else. But there is something wrong with the idea that we can have the best of both worlds, if we just try to make async code look like threaded code.