qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Sebastian Ottlik <ottlik@fzi.de>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 1/5] util: add socket_set_fast_reuse function which will replace setting SO_REUSEADDR
Date: Tue, 10 Sep 2013 10:34:46 -0600	[thread overview]
Message-ID: <522F4A26.8080805@redhat.com> (raw)
In-Reply-To: <522F4775.1070606@fzi.de>

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

On 09/10/2013 10:23 AM, Sebastian Ottlik wrote:

>>> +    if (ret < 0) {
>>> +        perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
>>> +    }
>> This would be the first use of perror in this file; I'm not sure if that
>> is the right function, or if there is a better thing to be using (in
>> fact, returning -1 and letting the client decide whether to issue a
>> warning may even be better).
>>
> When I started writing the patch I was going to return the error and lat
> the client handle the issue. But the code in net/socket.c then becomes:
> 
>     ret = socket_set_fast_reuse(fd);
>     if (ret < 0) {
>         perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
>         closesocket(fd);
>         return -1;
>     }
> 
> Which looked unclean to me, as the code implies assumptions about the
> implementation of socket_set_fast_reuse. One could also call
> perror("socket_set_fast_reuse()") but this would break the convention in
> the surrounding code of passing for the function that failed to perror.

Maybe a compromise?  Add a 'bool silent' flag to socket_set_fast_reuse,
and only issue perror() if the flag is false.  Existing callers that
don't care about failure (if we get fast reuse, great; if not, no huge
loss) pass false, existing callers that did their own error reporting
pass true to take advantage of the perror() on failure, and then you
aren't changing semantics at call sites.

But I'm just making this observation from the side; you might want to
get an opinion from an actual maintainer of this area of code on which
approach is best.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

  reply	other threads:[~2013-09-10 16:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10 13:26 [Qemu-devel] [PATCH v3 0/5] Do not set SO_REUSEADDR on Windows Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 1/5] util: add socket_set_fast_reuse function which will replace setting SO_REUSEADDR Sebastian Ottlik
2013-09-10 15:56   ` Eric Blake
2013-09-10 16:23     ` Sebastian Ottlik
2013-09-10 16:34       ` Eric Blake [this message]
2013-09-10 16:39         ` Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 2/5] gdbstub: call socket_set_fast_reuse instead of " Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 3/5] net: " Sebastian Ottlik
2013-09-10 15:53   ` Eric Blake
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 4/5] slirp: " Sebastian Ottlik
2013-09-10 15:58   ` Eric Blake
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 5/5] util: " Sebastian Ottlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=522F4A26.8080805@redhat.com \
    --to=eblake@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=ottlik@fzi.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).