Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
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




  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