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

Re: Fix signal handler

From
Jeff King <peff@peff.net>
Date
Feb 2, 2010, 22:32 UTC
Message-ID
<20100202223208.GB18781@sigill.intra.peff.net>
In-Reply-To
<4B689CC5.3000400@web.de>
On Tue, Feb 02, 2010 at 10:44:37PM +0100, Markus Elfring wrote:
Show 6 quoted lines
> > No, it's not a sig_atomic_t, but it is assignment of a single function
> > pointer that is properly declared as volatile. Is this actually a
> > problem on any known system?
> 
> Is it guaranteed to work on all supported software environments that an
> address can be atomically set?

I think you are missing my point. We are not coding to a set of standards that provide guarantees. We are coding to a practical set of real-world implementations that people try to run git on and produce bug reports for. I do not think anyone on this list could even enumerate a complete a list of the "supported software environments" of git.

We try to be conservative about portability issues. Some things are obviously wrong. But other things may violate the letter of some standards, and yet work in practice on all of the platforms people are interested in running git on.

I don't think anyone here is much interested in whether there is any sort of guarantee on a particular construct working. What we do care about is whether there is an actual problem on some platform that enough people care about to justify rewriting the code to handle it.

So to answer your question, I honestly don't know. The code may well be broken on common platforms and it is simply a race condition that has never come up. But I do know that it has not been a common source of bug reports, which makes me not want to spend time investigating it when nobody has demonstrated its incorrectness beyond mentioning a standards document. Especially when that time could be better spent fixing other bugs.

-Peff
Previous: Markus ElfringNext: Markus Elfring
Message 4 of 36 in “Fix signal handler”
  1. Markus ElfringFeb 2, 2010
  2. Jeff KingFeb 2, 2010
  3. Markus ElfringFeb 2, 2010
  4. Jeff KingFeb 2, 2010
  5. Markus ElfringFeb 3, 2010
  6. Jeff KingFeb 3, 2010
  7. Markus ElfringFeb 3, 2010
  8. Thomas RastFeb 3, 2010
  9. Markus ElfringFeb 3, 2010
  10. Shawn O. PearceFeb 3, 2010
  11. Andreas EricssonFeb 3, 2010
  12. Markus ElfringFeb 3, 2010
  13. Andreas EricssonFeb 4, 2010
  14. Jeff KingFeb 3, 2010
  15. Markus ElfringFeb 3, 2010
  16. Bill LearFeb 3, 2010
  17. Markus ElfringFeb 9, 2010
  18. Daniel BarkalowFeb 9, 2010
  19. Markus ElfringFeb 10, 2010
  20. Shawn O. PearceFeb 10, 2010
  21. Jeff KingFeb 10, 2010
  22. Jeff KingFeb 10, 2010
  23. Markus ElfringFeb 13, 2010
  24. Jeff KingFeb 14, 2010
  25. Junio C HamanoFeb 14, 2010
  26. Markus ElfringFeb 18, 2010
  27. Junio C HamanoFeb 18, 2010
  28. Markus ElfringFeb 19, 2010
  29. Markus ElfringFeb 22, 2010
  30. Junio C HamanoFeb 22, 2010
  31. Markus ElfringFeb 23, 2010
  32. Markus ElfringFeb 23, 2010
  33. Junio C HamanoFeb 23, 2010
  34. Markus ElfringFeb 24, 2010
  35. Andreas EricssonFeb 24, 2010
  36. Markus ElfringFeb 24, 2010

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.