On Tue, 2013-05-07 at 10:04 -0600, Erich E. Hoover wrote:
On Tue, May 7, 2013 at 3:14 AM, Hans Leidekker hans@codeweavers.com wrote:
... TerminateThread is not the right tool here. If the thread is blocked on the recv call while being terminated it will leak the netlink socket.
You'd need a way to synchronize the threads, but an overhead of one thread per caller is rather costly in the first place. This suggests that the server should poll the socket.
So far the iphlpapi hasn't been doing anything directly with the server... How about launching a single thread for NotifyAddrChange (when needed) and keeping a list of OVERLAPPED structures to signal
It's a system-wide event so the server seems to be a pretty good candidate to handle it, and it wouldn't need any extra threads.
when the list changes? It's easy enough to use MSG_DONTWAIT to make recv non-blocking so that it's easy to cancel the thread.
You'd be consuming cpu instead of properly waiting. I guess you could make this work if you poll an array with the netlink fd and another unix fd to signal the cancel event, but again, I think this is best handled by the server.