On 25/11/2024 19:15, Corinna Vinschen wrote:
Hi Christian,
On Nov 25 15:00, Christian Franke wrote:
Corinna Vinschen wrote:
Fixes: ...?
... the very first commit (cgf 2001) of sched.cc :-)
New patch attached.
From e95fc1aceb5287f9ad65c6c078125fecba6c6de9 Mon Sep 17 00:00:00 2001
From: Chr
Hi Corinna,
Corinna Vinschen wrote:
Hi Christian,
On Nov 25 15:00, Christian Franke wrote:
Corinna Vinschen wrote:
Fixes: ...?
... the very first commit (cgf 2001) of sched.cc :-)
New patch attached.
From e95fc1aceb5287f9ad65c6c078125fecba6c6de9 Mon Sep 17 00:00:00 2001
From: Christian Fr
Hey.
Just wanted to give this a bump, as it wasn't clearly rejected, but
merged either.
I mean the exceptions to the rule mentioned by Jon are still there,
aren't they.
And even if someone was going to write some option that provides output
in a more standardised format, I don't see much harm in
From: Jeremy Drake
If the Cygwin dll's architecture is different from the host system's
architecture, append an additional tag that indicates the host system
architecture (the Cygwin dll's architecture is already indicated in
machine).
Signed-off-by: Jeremy Drake
---
v2: get rid of hardcoded st
From: Jeremy Drake
This was already used in the FAST_CWD check, and could be used in a
couple other places.
I found the "emulated"/process value returned from the function largely
useless, so I did not cache it. It is useless because, as the docs say,
it is set to IMAGE_FILE_MACHINE_UNKNOWN (0)
Hi Christian,
On Nov 25 15:00, Christian Franke wrote:
> Corinna Vinschen wrote:
> > Fixes: ...?
>
> ... the very first commit (cgf 2001) of sched.cc :-)
>
> New patch attached.
>
> From e95fc1aceb5287f9ad65c6c078125fecba6c6de9 Mon Sep 17 00:00:00 2001
> From: Christian Franke
> Date: Mon, 25
Christian Franke wrote:
Long standing (2001) minor issue.
v2 with "Fixes:" in log message.
From 6c8c005a36a4f75f0dfd9f4c8e1db81ef1feedcc Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Mon, 25 Nov 2024 15:02:36 +0100
Subject: [PATCH] Cygwin: sched_getscheduler: fix error handling
Fixe
Corinna Vinschen wrote:
Hi Christian,
can you please add a Fixes: to the commit messages of both
of your patches?
On Nov 23 19:56, Christian Franke wrote:
sched_setscheduler(pid, sched_getscheduler(pid), param) should behave like
sched_setparam(pid, param).
--
Regards,
Christian
From a67e6
Previously, sig thread ran in THREAD_PRIORITY_HIGHEST priority.
This caused critical delay in signal handling in the main thread
if the too many signales are received rapidly and CPU is very busy.
I this case, most of CPU time is allocated to sig thread, so the
main thread cannot have a chance to h
On Mon, 25 Nov 2024 21:16:20 +0900
Takashi Yano wrote:
> Previously, sig thread ran in THREAD_PRIORITY_HIGHEST priority.
> This caused critical delay in signal handling in the main thread
> if the too many signales are received rapidly and CPU is very busy.
> I this case, most of CPU time is alloca
Previously, a deadlock happened if many SIGSTOP/SIGCONT signals were
received rapidly. If the main thread sends __SIGFLUSH at the timing
when SIGSTOP is handled by sig thread, but not is handled by main
thread yet (sig_handle_tty_stop() not called yet), and if SIGCONT is
received, the sig thread wa
This patch replaces pause instruction with SwitchToThread() call
in wait loop in lock() to increase the chance to unlock in other
threads.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 61522196c715 ("* Merge in cygwin-64bit-branch.")
Reported-by: Christian Franke
Previously, retry flag was always set when pending_signal::pending()
was called. However, if the queue is empty sig thread try to flush
the queue even though it was not necessary. With this patch, the
retry flag is set only if the queue is not empty.
Addresses: https://cygwin.com/pipermail/cygwin/
Previously, sig thread ran in THREAD_PRIORITY_HIGHEST priority.
This caused critical delay in signal handling in the main thread
if the too many signales are received rapidly and CPU is very busy.
I this case, most of CPU time is allocated to sig thread, so the
main thread cannot have a chance to h
The queue is once cleaned-up, however, sigpacket::process() may set
si_signo in the queue to 0 by calling sig_clear(). This patch adds
another loop for cleanup after calling sigpacket::process().
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 9d2155089e87 ("(wait_s
With previous code, queued signal is tried to resend only when a
new signal is arrived or pending_signals::pending() is called.
With this patch, if signal is queued and retry flag is not set
and new signal is not received yet, sig thread tries to handle
the queued signal again. Without this patch,
Takashi Yano (6):
Cygwin: signal: Fix deadlock between main thread and sig thread
Cygwin: signal: Handle queued signal without explicit __SIGFLUSH
Cygwin: signal: Cleanup signal queue after processing it
Cygwin: signal: Optimize the priority of the sig thread
Cygwin: signal: Drop unnecess
Hi Christian,
can you please add a Fixes: to the commit messages of both
of your patches?
On Nov 23 19:56, Christian Franke wrote:
> sched_setscheduler(pid, sched_getscheduler(pid), param) should behave like
> sched_setparam(pid, param).
>
> --
> Regards,
> Christian
>
> From a67e6679cc2bb19
On Nov 23 08:37, Jeremy Drake via Cygwin-patches wrote:
> From: Jeremy Drake
>
> It appears this is causing hangs on native x86_64 in similar scenarios
> as the hangs on ARM64, because `CancelSynchronousIo` is returning `TRUE`
> but not canceling the `ReadFile` call as expected.
>
> Addresses:
On Nov 22 08:54, Jeremy Drake via Cygwin-patches wrote:
> On Fri, 22 Nov 2024, Corinna Vinschen wrote:
>
> > On Nov 21 11:42, Jeremy Drake via Cygwin-patches wrote:
> > > +#if defined (__x86_64__)
> > > + host_mach = IMAGE_FILE_MACHINE_AMD64;
> > > +#elif defined (__i386__)
> > > + host_
On Nov 22 09:56, Jeremy Drake via Cygwin-patches wrote:
> On Fri, 22 Nov 2024, Corinna Vinschen wrote:
>
> > > wait_thread is happily waiting in ReadFile, while the main thread is
> > > hanging in ForceCloseHandle1 (close_h, rd_proc_pipe);.
> >
> > which is one of the great annoyances of Windo
On Nov 22 14:37, Christian Franke wrote:
> Corinna Vinschen wrote:
> > On Nov 20 22:00, Takashi Yano wrote:
> > > On Tue, 19 Nov 2024 11:51:17 +0100
> > > Corinna Vinschen wrote:
> > > > Maybe we can utilize WaitOnAddress, kind of like this?
> > > >
> > > > sigwait_common, just the fallthrough sni
22 matches
Mail list logo
