Ben Johnson wrote:
> What do you mean by the DNY lookup is asynchronous and will block my 
> process? If I was to call curl directly from the command line using 
> `curl` in ruby wouldn't that be much faster. In this instance it wo uld 
> get it's own process and take better advantage of a dual processor 
> system. Am I correct, because what I planned on doing was just using 
> curl directly from the command line unless there is a downside to this.

Odds are the process startup would take up more time than you'd gain. 
IMO that's NOT a good way to leverage a dual-core processor. Doing hacks 
like this only makes sense in a CPU-intensive application (which curl 
hardly is), and you want to split the work between two (or maybe more) 
*threads* more or less equally. You also want these threads being 
managed in a thread pool to avoid OS thread initialisation time. For 
added hilarity, you need native threads for this, not green threads - 
the OS can't schedule those on different cores.

Technically, you could do this using processes instead of threads. 
Except once again, you want to outweigh the process initialisation time, 
and the time it takes to transfer data between the processes, with the 
added performance eliminating context switches brings. Which just might 
not be all that easy.

David Vallner