From: pierre-marc.fournier@polymtl.ca (Pierre-Marc Fournier)
Subject: [ltt-dev] [UST PATCH] remove duplicate return
Date: Mon, 06 Sep 2010 16:14:24 -0400 [thread overview]
Message-ID: <4C854BA0.4040701@polymtl.ca> (raw)
In-Reply-To: <20100906152927.GA22968@Krystal>
On 09/06/2010 11:29 AM, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
>> * Pierre-Marc Fournier (pierre-marc.fournier at polymtl.ca) wrote:
>>> I disagree with you Mathieu. These retvals are the same as i/o
>>> syscalls (read/write/send/recv/...)and therefore should in my opinion
>>> remain as is.
>>
>> Well, this function is not technically the same as i/o syscalls at all.
>> It uses I/O syscalls, but it is not an I/O syscall per se, so the return
>> value transformation to a more standard pattern (neg err val, 0 ok)
>> should happen right in this function rather than to let all callers
>> handle this. I/O syscalls use positive return values to indicate the
>> number of bytes read/written/etc. Here, this function arbitrarily choose
>> 1 to indicate that "something has been sent" without caring about the
>> amount of data moved at all.
>>
>> So as it doesn't need the whole positive range to spell out the amount
>> of data moved, it doesn't need to do the same special-cases that the I/O
>> syscalls are doing. It adds a lot of error values management oddness
>> without adding anything.
>>
>> So even though I agree with you that this function is close to the I/O
>> system calls because it calls it, it is very far from the I/O syscalls
>> semantically (we don't care about the number of bytes written), and even
>> though we might be tempted to use the same error values as system calls
>> for them, the fact that we just don't care about the number of bytes
>> written combined with the fact that standardizing error value across the
>> code makes it much easier to follow and to write just call for this
>> change.
>
> By the way, looking at include/share.h:patient_write(), in the case
> where write returns 0, I think we should consider this as a success and
> loop again to retry write rather than consider that an error occurred.
> The same apply to patient_send(). See the manpages for details:
>
> write(2):
>
> RETURN VALUE
> On success, the number of bytes written is returned (zero indicates
> nothing was written). On error, -1 is returned, and errno is set
> appropriately.
>
> If count is zero and fd refers to a regular file, then write() may
> return a failure status if one of the errors below is detected. If no
> errors are detected, 0 will be returned without causing any other
> effect. If count is zero and fd refers to a file other than a regular
> file, the results are not specified.
>
> send(2):
> RETURN VALUE
> On success, these calls return the number of characters sent. On
> error, -1 is returned, and errno is set appropriately.
>
No. 0 indicates end of stream and looping on it will result in an
infinite loop. You need to refer to the specific backend driver to
understand these specific semantics. The read/write manpages are
notorious for their non-clarity about this.
pmf
next prev parent reply other threads:[~2010-09-06 20:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 23:26 Douglas Santos
2010-09-06 0:49 ` Mathieu Desnoyers
2010-09-06 1:03 ` Pierre-Marc Fournier
2010-09-06 2:42 ` Mathieu Desnoyers
2010-09-06 15:29 ` Mathieu Desnoyers
2010-09-06 20:14 ` Pierre-Marc Fournier [this message]
2010-09-07 15:43 ` Mathieu Desnoyers
2010-09-08 16:29 ` David Goulet
2010-09-08 16:40 ` Mathieu Desnoyers
2010-09-09 7:10 ` Pierre-Marc Fournier
2010-09-09 16:38 ` Mathieu Desnoyers
2010-09-09 17:05 ` David Goulet
2010-09-11 18:36 ` Nils Carlson
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=4C854BA0.4040701@polymtl.ca \
--to=pierre-marc.fournier@polymtl.ca \
/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