[PATCH v2] Cygwin: signal: Redesign signal queue handling

The previous implementation of the signal queue behaves as: 1) Signals in the queue are processed in a disordered manner. 2) If the same signal is already in the queue, new signal is discarded. Strictly speaking, these behaviours do not violate POSIX. However, these could be a cause of unexpected

Re: [PATCH] fix native symlink spawn passing wrong arg0

Hi Chris, On Mar 10 21:08, Chris Denton wrote: > Currently when starting a process from bash via a native symlink, argv[0] is > set to the realpath of the executable and not to the link name. This patch > fixes > it so the path of the symlink is seen instead. > > The cause is a path conversion i

Re: [PATCH] Cygwin: signa: Redesign signal queue handling

On Tue, 11 Mar 2025 11:28:57 +0100 Corinna Vinschen wrote: > On Mar 11 17:56, Takashi Yano wrote: > > On Mon, 10 Mar 2025 21:57:52 +0100 > > Corinna Vinschen wrote: > > > On Mar 9 13:28, Christian Franke wrote: > > > > Takashi Yano wrote: > > > > > ... > > > > > With this patch prevents all signal

Re: [PATCH] Cygwin: signa: Redesign signal queue handling

On Tue, 11 Mar 2025 20:50:05 +0900 Takashi Yano wrote: > BTW, I found another bug in signal handling. > > The following testcase (that is the modified version of Christian's one) > hangs with my v2 signal queue patch. Not always, but sometimes. > It seems that the signal handler > is called from

Re: [PATCH] Cygwin: signa: Redesign signal queue handling

On Mar 11 17:56, Takashi Yano wrote: > On Mon, 10 Mar 2025 21:57:52 +0100 > Corinna Vinschen wrote: > > On Mar 9 13:28, Christian Franke wrote: > > > Takashi Yano wrote: > > > > ... > > > > With this patch prevents all signals from that issues by redesigning > > > > the signal queue, Only the exce

Re: [PATCH] Cygwin: signa: Redesign signal queue handling

On Mon, 10 Mar 2025 21:57:52 +0100 Corinna Vinschen wrote: > On Mar 9 13:28, Christian Franke wrote: > > Takashi Yano wrote: > > > ... > > > With this patch prevents all signals from that issues by redesigning > > > the signal queue, Only the exception is the case that the process is > > > in the

[PATCH v3 0/6] Several fixes for signal handling

Split the v2 patch into smaller parts and add two additional patches Takashi Yano (6): Cygwin: signal: Redesign signal queue handling Cygwin: signal: Do not clear signals in the queue Cygwin: signal: Ignore SIGSTOP while process is already stopping Cygwin: signal: Do not send __SIGFLUSHFAS

[PATCH v3 3/6] Cygwin: signal: Ignore SIGSTOP while process is already stopping

On Linux, SIGSTOP while the process is stopping is ignored. With this patch, SIGSTOP is processed as a success with no effect while the process is already stopping. Fixes: 8f8eeb70ba73 ("* exceptions.cc (sigpacket::process): ...") Reviewed-by: Signed-off-by: Takashi Yano --- winsup/cygwin/except

[PATCH v3 6/6] Cygwin: signal: Remove context_copy in call_signal_handler()

After the commit 1d97f8aa4385, context_copy in call_signal_handle() is not used anymore. This patch removes it. Fixes: 1d97f8aa4385 ("Cygwin: signals: don't evaluate SA_SIGINFO context after handler returns") Reviewed-by: Signed-off-by: Takashi Yano --- winsup/cygwin/exceptions.cc | 3 +-- 1 fi

[PATCH v3 2/6] Cygwin: signal: Do not clear signals in the queue

Currently, sigpacket::process() clears some signals from the queue. For instance, SIGSTOP clears SIGCONT and SIGCONT clears SIGSTOP, etc. These might be needed by previous queue design, however, new queue design does not require that. On the contrary, that causes signal lost. With this patch, these

[PATCH v3 1/6] Cygwin: signal: Redesign signal queue handling

The previous implementation of the signal queue behaves as: 1) Signals in the queue are processed in a disordered manner. 2) If the same signal is already in the queue, new signal is discarded. Strictly speaking, these behaviours do not violate POSIX. However, these could be a cause of unexpected

[PATCH v3 4/6] Cygwin: signal: Do not send __SIGFLUSHFAST if the pipe/queue is full

If __SIGFLUSHFAST is sent while the signal queue or the pipe is full, it causes deadlock. The mechanism is as follows. When sending __SIGFLUSHFAST, sig_send() waits for response (wakeup event) from wait_sig(). Therefore, the main thread does not process signals while waiting the wakeup event. Howe

[PATCH v3 5/6] Cygwin: signal: Use context locally copied in call_signal_handler()

If the signal handler is called from inside of another signal handler, _cygtls::context may be destroyed by call_signal_handler() newly called. To avoid this situation, this patch used context locally copied in call_signal_handler(). Addresses: https://cygwin.com/pipermail/cygwin-patches/2025q1/01

Re: [PATCH v3 5/6] Cygwin: signal: Use context locally copied in call_signal_handler()

On Wed, 12 Mar 2025 12:27:31 +0900 Takashi Yano wrote: > If the signal handler is called from inside of another signal handler, > _cygtls::context may be destroyed by call_signal_handler() newly called. > To avoid this situation, this patch used context locally copied in > call_signal_handler(). >