Well, there may be some value in using threads (or fork) here, but you will probably have to focus on making your code efficient to make it work well.
If I were you I'd run a fairly small bunch of concurrent processes or threads (not a lot more than you have CPUs in your target machine) that would each do asynchronous DHCP requests (in other words, have each thread initiate a lot of requests, and handle the responses as they come in, instead of waiting for the response before doing the next request).
An event handling system is going to be much more efficient than threads for this kind of problem, and the only reason you really want to use threads or fork is to spread the load better over multiple processors (though you may not even need to).
| [reply] |
Unless the machine has multiple interface cards, there is very little if any benefit in using multiple threads or processes, or an event driven architecture, as regardless of the presence of multiple cpus, all the outbound packets will be serialised at the interface card.
He might as well just run a tight loop issuing requests as fast as the processor/interface can send them.
As UDP is connectionless, at most, he might benefit from two threads/processes per cpu. One to send as fast as possible and another to receive replies assuming he is going to bother.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
In mostly I agree, especially about the connectionless part, but using more threads /may/ speed things up a bit more, just because any overhead not bound to the network interface can be spread over multiple CPUs. You're right the gains probably won't be very significant, though.
| [reply] |