dhcpcd has a lot of global variables. For a traditional UNIX environment this makes a lot of sense, when working as a single master daemon or in a daemon per interface model. But for a threaded model, this is very very bad because you then have competing threads wanting the same global resource. It Just Won't Work. Now threading has no place in dhcpcd because it's just plain silly.
However ..... how about dhcpcd running in a pure threaded single process environment as found in Real Time OSs? Now it becomes more interesting because you can no longer use signalling and you really are restricted to a single shot dhcpcd controlling all interfaces. It could be argued that not having any global variables is just a better programming practice, but I'm not entirely sold on that one.
Anyway, I've recently committed quite a large patch to dhcpcd which passes a context to a functions which would otherwise have none so that every single function and operation can safely work in a threads based environment.
Now, I need to improve the control socket so that the dhcpcd commandline works the same way entirely without signals. fun times!