On 11 November 2015 at 21:57, David Nicol <[email protected]> wrote: > it is entirely possible to write code that uses threads on Win32 and forks > on POSIX by abstracting the communication bits generically. Signalling could > work over pipes on both. > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx
Hum... yes of course, but I don't see how that addresses my concern. My point was, we either need to do something different between Win32 and POSIX (whether that implies different thread APIs or different process models is besides the point), which means we'll end up with #ifdefs (which is not great, because that makes code harder to maintain). Or we add a dependency on pthreads-win32 on Windows so that we can write the same code on both platforms. It's mostly a matter of taste really. (Personally I'm leaning towards the latter.) I'm not really concerned with communication. In fact I'm pretty sure the UPnP thread wouldn't have to communicate with tinc at all: it's pretty much a fire-and-forget affair. The UPnP code would only need to know which ports to forward, a parameter that can be provided at thread start. Afterwards, the thread would just keep the UPnP mapping alive indefinitely without having to talk to tinc at all. Therefore there's no need for pipes. (I realize that this means UPnP support could possibly be achieved simply by suggesting that the user spawn some standalone UPnP client process in the background from the tinc-up hook. That's not very user-friendly, though. Especially on Windows.) _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
