----- Forwarded message from Sebastian Ottlik <ottlik@fzi.de> -----

This patchset disabels all use of SO_REUSEADDR on Windows. On Windows systems the default behavior is equivalent to SO_REUSEADDR on other operating systems. SO_REUSEADDR can still be set but results in undesired bahvior instead. It may even lead to situations were system behavior is unspecified. More information on this can be found at: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621.aspx

----- End forwarded message ----- Read that doc and cry. In summary - On UNIX, SO_REUSEADDR allows an application to re-bind to a socket while it is in the CLOSE_WAIT state. - On Windows, you can always bind to a socket in CLOSE_WAIT state and AFAIK you can't disable this behaviour. Setting SO_REUSEADDR lets you bind to a socket when in *any* state. So if code originating on Linux is blindly setting SO_REUSEADDR it is almost certainly broken on Windows. Windows' interpretation of SO_REUSEADDR is somewhat closer to the new Linux v3.9 flag SO_REUSEPORT http://freeprogrammersblog.vhex.net/post/linux-39-introdued-new-way-of-writi... https://lwn.net/Articles/542629/ but the behaviour of SO_REUSEADDR is undefined on Windows for non-multicast sockets, while Linux explicitly says it'll round-robin accept() calls, so they're still not a perfect match. So without a way to 100% map the different semantics I don't think its practical for gnulib to save us from this madness and so we'll just want to #ifndef WIN32 the use of SO_REUSEADDR in Libvirt Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|