Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/07/2025 11:41, Carlo Marcelo Arenas Belón wrote:
On Mon, Jul 07, 2025 at 05:11:12PM -0800, Junio C Hamano wrote:

* cb/daemon-reap-children (2025-06-26) 4 commits
  - daemon: explicitly allow EINTR during poll()
  - daemon: use sigaction() to install child_handler()
  - compat/mingw: allow sigaction(SIGCHLD)
  - compat/posix.h: track SA_RESTART fallback

  Futz with SIGCHLD handling in "git daemon".

  Stalled?
  cf. <dba9ae0d-1e43-4345-a7ec-b57a07d45a07@xxxxxxxxx>
  source: <pull.2002.v3.git.git.1750927988.gitgitgadget@xxxxxxxxx>

I don't think so, but definitely missing reviews (specially for patch 2)
and slightly controversial.

I wasn't planning any further changes,

I'd very much like to see a re-roll cf. <b1027221-3e17-40d2-b293-4b1625fa095d@xxxxxxxxx>

Thanks

Phillip

and while I have some for the
"related" patchset which enhances the notifications by using a self pipe
was holding them (as well as the related feedback) to allow for this to
mature on its own.

On the rationale on why this is independently useful, note that we are
currently relying in at least 2 "unspecified" behaviours:

1) using signal() means that it is implementation defined if SA_RESTART
will be enabled or not for that signal, and
2) if SA_RESTART is enabled, it is implementation defined if we might get
interrupted in poll().

both are resolved by using sigaction() instead, and it is up to us to
decide if SA_RESTART is enabled or not (which might make patch 4 obsolete
if we decide against).

Carlo

CC: Johannes Sixt on feedback for SIGCHLD in mingw which uses 17 instead
     of 22 (cygwin and others) and therefore seem to cause signal to err
     without setting errno as it should.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux