<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 3:04 PM, Etienne Dechamps <span dir="ltr"><<a href="mailto:etienne@edechamps.fr" target="_blank">etienne@edechamps.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">miniupnpc only provides a blocking API, there is no way to<br>
integrate it into an event loop. That pretty much means we will need<br>
to run the UPnP code in a separate thread. Which means using pthreads<br>
on POSIX, and then we would either have a dependency on pthreads-Win32<br>
on Windows, or we would need to #ifdef Win32 thread code in.<br>
<br>
I'm wondering what your thoughts are on this topic. I can definitely<br>
give miniupnpc integration a try if you are okay with adding these<br>
extra dependencies to tinc. It would be very easy to provide a<br>
configure option to disable UPnP support, making these new<br>
dependencies less of a concern.<br></blockquote><br></div><div class="gmail_quote"><br>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.<br><br><a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx">https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx</a><br></div><div class="gmail_quote"><br><br><br></div></div></div>