On Tue, 2013-05-07 at 10:04 -0600, Erich E. Hoover wrote: > On Tue, May 7, 2013 at 3:14 AM, Hans Leidekker <h...@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.
