On 02/12/2011, at 7:16 PM, Richard Heycock wrote: > That, however, is not the main cause for concern! Given that you > are running async code in the model you will get a non-local return > error (from memory - it's been a while since I've used EM based code > in rails). So you need to sync it using fibers. That's pretty much > the only way and it dosen't actually gain you anything! You could use > em-synchrony to give the impression that you are writing "normal ruby" > but that still uses fibbers.
So Fibers are basically the only option here (with or without em-synchrony)? Which means no Ruby 1.8. I guess I can sacrifice that but would prefer not to. I will look at em-synchrony closer. Thanks for that. > You might be able to do something funky by spinning up a thread at startup > in which you would run some EM code that listens on a named pipe so you > could write a message to that from the rails code. But that sounds like > more trouble than it's worth. Yeah, definitely. Sounds a bit more complex than I'd like it to be. > I would suggest that you best bet is to have an independent process that > does the downloading for you such as cloudist or one of the many other > job queues. Didn't know about cloudist. Will remember. But queue doesn't seem to be the right tool for me. The HTTP requests are basically the Database queries, so I can't postpone those much as the results will be necessary within a request. So I just want to make those queries parallel but in such a way so that clients of the library don't have to deal with it. It looks like em-synchrony is the best bet so far. Thanks a lot for your help. Cheers. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
