All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: RE: [Proposed Fix] daemon.c: not initializing revents
Date: Tue, 12 Feb 2019 08:58:08 -0500	[thread overview]
Message-ID: <000201d4c2da$feff72c0$fcfe5840$@nexbridge.com> (raw)
In-Reply-To: <xmqqd0nxg1a1.fsf@gitster-ct.c.googlers.com>

On February 11, 2019 21:59, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> >> In any case, no matter what POSIX says, if clearing .revents before
> > calling
> >> poll() helps on platforms in the real world, the patch is worth
> >> taking as
> > a fix, I
> >> would think.
> >
> > That's what my intent was - my explanations are suffering from a
> > little work-induced sleep deprivation. Would you like this as a formal
> patch?
> 
> That depends ;-)
> 
> At this late in the cycle, I do not see much urgency for this patch to be
in the
> upcoming release (after all, this code survived real world for quite a
long
> time, so it's only minority platforms like NonStop that haven't seen
serious
> porting effort until recently that would see improvement---and they have
> survived without reliably working daemon for so long that they can wait
for
> one more release).
> 
> Now, the knowledge that we will have long enough time before the final
> version of the formal patch becomes necessary makes me wonder what the
> best use of that time to polish the patch would be.  Ideally we'd like to
see
> "this definitely fixed (or 'worked around') such and such breakages on
> platform X, Y and Z" instead of my "Well, we could read POSIX that way, so
> there may be some platforms that would require applications to do this,
and
> an extra assignment here would certainly not hurt", which was the hand-
> waving I just did.
> 
> I dunno.

I hear that. I'd rather (not) be working on debugging breakages from other
authors that impact my platform. Honestly, I'd rather work at my $DAYJOB,
although, some days...

Since this topic isn't a breakage per-se (no tests seem to be impacted on
way or another), I agree that this can wait and get through the normal cycle
of events at some point in the future. Now, if I could only get some help on
t5562 ;) that would be time well spent for rc0.

Cheers,
Randall


      reply	other threads:[~2019-02-12 13:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000901d4c0b1$1ea15160$5be3f420$@nexbridge.com>
2019-02-09 19:56 ` [Proposed Fix] daemon.c: not initializing revents Randall S. Becker
2019-02-11 20:56   ` Junio C Hamano
2019-02-11 21:44     ` Randall S. Becker
2019-02-12  2:59       ` Junio C Hamano
2019-02-12 13:58         ` Randall S. Becker [this message]

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='000201d4c2da$feff72c0$fcfe5840$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.