git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Lars Schneider <larsxschneider@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	gitster@pobox.com, jnareb@gmail.com, mlbright@gmail.com,
	e@80x24.org, Johannes.Schindelin@gmx.de, ben@wijen.net
Subject: Re: [PATCH v5 02/15] pkt-line: call packet_trace() only if a packet is actually send
Date: Wed, 10 Aug 2016 15:51:35 +0200	[thread overview]
Message-ID: <9BF0767F-6B10-42D5-9A72-2710A753E26A@gmail.com> (raw)
In-Reply-To: <20160810133017.ovdx3a3ldqj5gl7q@sigill.intra.peff.net>


> On 10 Aug 2016, at 15:30, Jeff King <peff@peff.net> wrote:
> 
> On Wed, Aug 10, 2016 at 03:24:38PM +0200, Lars Schneider wrote:
> 
>>> On Wed, Aug 10, 2016 at 03:03:58PM +0200, larsxschneider@gmail.com wrote:
>>> 
>>>> From: Lars Schneider <larsxschneider@gmail.com>
>>>> 
>>>> The packet_trace() call is not ideal in format_packet() as we would print
>>>> a trace when a packet is formatted and (potentially) when the packet is
>>>> actually send. This was no problem up until now because format_packet()
>>>> was only used by one function. Fix it by moving the trace call into the
>>>> function that actually sends the packet.
>>> 
>>> It looks like there are two functions: packet_write() and
>>> packet_buf_write().
>> 
>> I did not call trace in packet_buf_write() because this function does not
>> perform any writes.
> 
> Yes, but then who is responsible for the trace? The caller?

From my point of view the one that issues the write call.


> And why is it a bad thing to do it some time other than writing? It is
> if you format and then _don't_ write the packet, but the current callers
> are not doing that.

True, they don't do that. However, I don't think that is intuitive behavior
for future callers. If I call "format" and then trace tells me that a packet
was sent although it was not (yet).

> 
>>> Your patch only touches one of them, and it looks like we would fail to
>>> trace many packets (e.g., see receive-pack.c:report(), which uses
>>> packet_buf_write() and then write()s out the result).
>> 
>> I see. But isn't it confusing if packet_buf_write() issues a trace call?
>> If I just call this function then nothing happens at all. Shouldn't the
>> trace call be made in receive-pack.c:report() ? Or shouldn't receive-pack
>> let pkt-line.c perform the write calls?
> 
> How would report() do that without re-parsing each of the packets?

We could add a function to pkt-line that takes a list of strings and
generates a list of packets with a terminating flush packet out of it.
Then it sends the packets.

As a quick compromise we could also introduce a function "packet_buf_write_with_trace()"
that wraps the "packet_buf_write()" and calls trace. However, I can imagine that
would be perceived as ugly.

I guess my point is that I stumbled over the un-intutiive format_packet() behavior
and I wanted to improve the situation in a way that others don't run into this
trap. If you think that is no issue then it would be OK for me if we leave the
current behavior as is.

Thanks,
Lars





  reply	other threads:[~2016-08-10 19:22 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160803164225.46355-1-larsxschneider@gmail.com/>
2016-08-10 13:03 ` [PATCH v5 00/15] Git filter protocol larsxschneider
2016-08-10 13:03   ` [PATCH v5 01/15] pkt-line: extract set_packet_header() larsxschneider
2016-08-10 13:03   ` [PATCH v5 02/15] pkt-line: call packet_trace() only if a packet is actually send larsxschneider
2016-08-10 13:13     ` Jeff King
2016-08-10 13:24       ` Lars Schneider
2016-08-10 13:30         ` Jeff King
2016-08-10 13:51           ` Lars Schneider [this message]
2016-08-10 14:33             ` Jeff King
2016-08-10 13:03   ` [PATCH v5 03/15] pkt-line: add `gentle` parameter to format_packet() larsxschneider
2016-08-10 13:15     ` Jeff King
2016-08-10 13:29       ` Lars Schneider
2016-08-10 13:37         ` Jeff King
2016-08-10 13:59           ` Lars Schneider
2016-08-10 14:34             ` Jeff King
2016-08-10 13:04   ` [PATCH v5 04/15] pkt-line: add packet_write_gently() larsxschneider
2016-08-10 13:28     ` Jeff King
2016-08-10 13:36       ` Lars Schneider
2016-08-10 13:40         ` Jeff King
2016-08-10 17:17           ` Junio C Hamano
2016-08-10 17:49             ` Lars Schneider
2016-08-10 18:21               ` Junio C Hamano
2016-08-10 19:15                 ` Lars Schneider
2016-08-10 13:04   ` [PATCH v5 05/15] pkt-line: add packet_write_gently_fmt() larsxschneider
2016-08-10 13:43     ` Jeff King
2016-08-10 14:10       ` Lars Schneider
2016-08-10 15:01         ` Jeff King
2016-08-10 17:18       ` Junio C Hamano
2016-08-10 17:53         ` Lars Schneider
2016-08-10 18:42           ` Junio C Hamano
2016-08-10 13:04   ` [PATCH v5 06/15] pkt-line: add packet_flush_gently() larsxschneider
2016-08-10 13:04   ` [PATCH v5 07/15] pkt-line: add functions to read/write flush terminated packet streams larsxschneider
2016-08-10 13:04   ` [PATCH v5 08/15] pkt-line: rename packet_write() to packet_write_fmt() larsxschneider
2016-08-10 13:04   ` [PATCH v5 09/15] pack-protocol: fix maximum pkt-line size larsxschneider
2016-08-10 13:04   ` [PATCH v5 10/15] convert: quote filter names in error messages larsxschneider
2016-08-10 13:04   ` [PATCH v5 11/15] convert: modernize tests larsxschneider
2016-08-10 13:04   ` [PATCH v5 12/15] convert: generate large test files only once larsxschneider
2016-08-10 13:04   ` [PATCH v5 13/15] convert: make apply_filter() adhere to standard Git error handling larsxschneider
2016-08-10 13:04   ` [PATCH v5 14/15] convert: add filter.<driver>.process option larsxschneider
2016-08-12 16:33     ` Stefan Beller
2016-08-12 16:38       ` Jeff King
2016-08-12 16:48         ` Stefan Beller
2016-08-12 17:08           ` Lars Schneider
2016-08-12 17:13             ` Junio C Hamano
2016-08-12 17:21               ` Lars Schneider
2016-08-12 18:03                 ` Junio C Hamano
2016-08-12 16:59       ` Lars Schneider
2016-08-12 17:07         ` Stefan Beller
2016-08-12 17:14           ` Lars Schneider
2016-08-10 13:04   ` [PATCH v5 15/15] read-cache: make sure file handles are not inherited by child processes larsxschneider
2016-08-18 14:23     ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=9BF0767F-6B10-42D5-9A72-2710A753E26A@gmail.com \
    --to=larsxschneider@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ben@wijen.net \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=mlbright@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).