qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] Do not set SO_REUSEADDR on Windows


From: Michael Tokarev
Subject: Re: [Qemu-devel] [PATCH RFC] Do not set SO_REUSEADDR on Windows
Date: Thu, 05 Sep 2013 11:36:18 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8

04.09.2013 18:34, Jan Kiszka wrote:
On 2013-09-04 16:27, Paolo Bonzini wrote:
Il 04/09/2013 16:22, Sebastian Ottlik ha scritto:
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

I originally encountered this issue when accidentally launching two QEMU
instances with identical GDB ports at the same time. In which case QEMU won't
fail as one might expect. I am sending this as RFC as I A) only checked that
this fixes issues for the GDB server and B) am not sure if this is the correct
format for this patchset.

gdbstub: do not set SO_REUSEADDR on Windows
net: do not set SO_REUSEADDR on Windows
slirp: do not set SO_REUSEADDR on Windows
util: do not set SO_REUSEADDR on Windows

Makes sense.

Can you make a different patch that introduces a new function
qemu_set_reuseaddr is include/qemu/sockets.h & util/oslib-*, and makes
it a stub for Windows?

Maybe a better approach will be to introduce something like
qemu_[stream_]listen_socket(int family, sockaddr_t *sa, int salen) function
which opens and prepares a socket with all necessary platform-dependent
stuff?

Yeah, this is definitely better then. IIRC, Michael has some version of
patch 3 in his queue right now - should be dropped in this light.

It's been pulled by Anthony yesterday so it is a bit too late now.
But the change is trivial, and can be reworked easily.

Thanks,

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]