Piers Cawley wrote: > Piers Cawley <[EMAIL PROTECTED]> writes: > >> Piers Cawley <[EMAIL PROTECTED]> writes: >> >>> The catch is, IPSocket.getaddress, which is what we use for DNS >>> lookups, appears to be be a blocking call, which with the nature of >>> Ruby threads, means it'll *still* hold up processing during the >>> lookup. >>> >>> Thoughts? >> Hmm... resolv.rb may be our friend. And (bonus points!) it's in the >> standard library. > > And, following further work on using threads, I'd just like to say > that threading is weird and is currently doing my head in. Background > classification sort of works, but only very approximately.
Would it not be possible to take the same approach as mod_perl and schedule some code to run immediately after the current request, but before the next one (a cleanup handler)? It would still mean that particular fastcgi process was unavailable, but it would mean that you could return to the user quicker. Unfortunately, a quick look in railties at the dispatcher shows that rails doesn't offer anything like this. Damn. -Dom _______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
