git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

From
Jeff King <peff@peff.net>
Date
Jun 27, 2016, 19:51 UTC
Message-ID
<20160627195138.GA15147@sigill.intra.peff.net>
In-Reply-To
<CAGZ79kZWfGJG=qHtdpuLvQY5XK5P3L0UW7RJ=9ui=PgX+AjErQ@mail.gmail.com>
On Mon, Jun 27, 2016 at 12:43:32PM -0700, Stefan Beller wrote:
Show 8 quoted lines
> There are a few issues:
> 
>     1) How did you spot the bug? ("Experience/Logical thinking" is the hand
>       wavy answer, but if you had a list like
>       [ ] check for mem leak
>       [ ] check for futureproof design
>       [ ] check for failure modes (What if a syscall fails?")
>       [ ] ... List is not complete, but has some made up points

I use the hand-wavy approach to reviews, and I'm pretty sure that's how I saw your bug (just thinking about what the code would do, how I would write it, and then noticing a discrepancy).

I suspect a checklist could make things more thorough, but I think it can also discourage deep thinking. Ideally we have some reviewers who are checklist-oriented looking for those sorts of details and some who are not.

>     2) I used to send out only "done"s, i.e. when I already fixed the
>     issue, instead of acknowledging the problem and postponing the fix
>     for later.  I'll revert to that.

Yes, I tend to use the review thread as a todo list, and do a single session where I read over all of the review mails again (even if I've read and responded to them already), fixing or adjusting the code. Sort of a human version of the automated tool I described. :)

Show 5 quoted lines
> > Of course, none of that would have helped my comment, which was in a
> > "PS" several emails deep in a discussion thread. ;)
> 
> Maybe a "P.S." would get its own point in the todo list not associated
> with code?  Then it would still be on the radar.

Yes, there are definitely design points that are not about a specific part of the code, and you would want to somehow represent them in your todo list.

There is a danger, though, of having a bunch of false positives added to your list: tangent discussion that distracts you from the actual review. And I think the bug here being in a PS is less relevant than being buried amidst other discussion. That made it hard for a tool _or_ a human to find.

-Peff
Previous: Stefan BellerNext: Eric Wong
Message 9 of 17 in “wrapper: xread/xwrite fixes for non-blocking FDs”
  1. 0/2 wrapper: xread/xwrite fixes for non-blocking FDsEric Wong, Jun 26, 2016
  2. 1/2 xread: retry after poll on EAGAIN/EWOULDBLOCKEric Wong, Jun 26, 2016
  3. Jeff KingJun 26, 2016
  4. Junio C HamanoJun 27, 2016
  5. Jeff KingJun 27, 2016
  6. Stefan BellerJun 27, 2016
  7. Jeff KingJun 27, 2016
  8. Stefan BellerJun 27, 2016
  9. Jeff KingJun 27, 2016
  10. Eric WongJun 27, 2016
  11. Jeff KingJun 27, 2016
  12. Jeff KingJun 27, 2016
  13. Eric WongJun 27, 2016
  14. Jeff KingJun 26, 2016
  15. 1/2 xread: retry after poll on EAGAIN/EWOULDBLOCKEric Wong, Jun 27, 2016
  16. 2/2 xwrite: poll on non-blocking FDsEric Wong, Jun 26, 2016
  17. Jeff KingJun 26, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.