Dominic Mitchell <[EMAIL PROTECTED]> writes: > 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.
Sadly not. Some of the spam checks I've seen in my logs have taken the best part of a minute. Tie up a couple of dispatchers like that and your performance is screwed. > Unfortunately, a quick look in railties at the dispatcher shows that > rails doesn't offer anything like this. Damn. Monkey patching the dispatcher to allow it isn't exactly hard. But see above. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/ _______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
