On Fri, 29 Nov 2024, Corinna Vinschen wrote:
> On Nov 27 14:04, Jeremy Drake via Cygwin-patches wrote:
> > https://gist.github.com/jeremyd2019/aa167df0a0ae422fa6ebaea5b60c80c9
>
> Nice! If you feel confident to merge something like this into
> Cygwin, feel free to send patches.
I've found a litt
On Dec 3 08:23, Brian Inglis wrote:
> On 2024-12-03 06:13, Corinna Vinschen wrote:
> > On Dec 3 10:20, Christian Franke wrote:
> > > SCHED_IDLE: Ignore nice value and set IDLE_PRIORITY_CLASS ?
> >
> > Would make sense, I guess.
> > [...]
> > SCHED_SPORADIC is a bit of a problem. It requires ext
On 2024-12-03 06:13, Corinna Vinschen wrote:
On Dec 3 10:20, Christian Franke wrote:
Brian Inglis wrote:
On 2024-12-02 11:28, ASSI wrote:
Christian Franke writes:
+ nice value sched_priority Windows priority class
+ 12...19 16 IDLE_PRIORITY_CLASS
+ 4...11
On Tue, 3 Dec 2024 15:31:01 +0100
Corinna Vinschen wrote:
> On Dec 3 23:01, Takashi Yano wrote:
> > Previously, the sig thread ran in THREAD_PRIORITY_HIGHEST priority.
> > This causes a critical delay in the signal handling in the main
> > thread if too many signals are received rapidly and the CP
Corinna Vinschen wrote:
On Dec 3 10:20, Christian Franke wrote:
Brian Inglis wrote:
On 2024-12-02 11:28, ASSI wrote:
Christian Franke writes:
+ nice value sched_priority Windows priority class
+ 12...19 16 IDLE_PRIORITY_CLASS
+ 4...11 7...12 BELO
On Tue, 3 Dec 2024 15:41:45 +0100
Corinna Vinschen wrote:
> On Dec 3 23:01, Takashi Yano wrote:
> > The queue is cleaned up by removing the entries having si_signo == 0
> > while processing the queued signals, however, sigpacket::process() may
> > set si_signo in the queue to 0 of the entry alread
On Dec 3 23:01, Takashi Yano wrote:
> The queue is cleaned up by removing the entries having si_signo == 0
> while processing the queued signals, however, sigpacket::process() may
> set si_signo in the queue to 0 of the entry already processed but not
> succeed by calling sig_clear(). This patch e
On Dec 3 23:01, Takashi Yano wrote:
> If process() failed and the signal remains in the queue, the most
> possible reason is that the target thread already armed by another
> signal and do not handle it yet. With this patch, to increase the
> chance of handling it in the other threads, call yield(
On Dec 3 23:01, Takashi Yano wrote:
> Previously, the sig thread ran in THREAD_PRIORITY_HIGHEST priority.
> This causes a critical delay in the signal handling in the main
> thread if too many signals are received rapidly and the CPU is very
> busy. In this case, most of the CPU time is allocated
Hi Radek,
can you send this patch, as well as the newlib patch, as git patch with
subject line commit message and Signed-off-by, please?
`git format-patch' and `git send-email' are a great help there.
Thanks,
Corinna
On Dec 3 11:32, Radek Barton via Cygwin-patches wrote:
> GCC 15 enables `-s
On Tue, 3 Dec 2024 21:39:33 +0900
Takashi Yano wrote:
> On Mon, 2 Dec 2024 16:18:15 +0100
> Corinna Vinschen wrote:
> > On Nov 29 20:59, Takashi Yano wrote:
> > > Previously, the sig thread ran in THREAD_PRIORITY_HIGHEST priority.
> > > This causes a critical delay in the signal handling in the mai
The queue is cleaned up by removing the entries having si_signo == 0
while processing the queued signals, however, sigpacket::process() may
set si_signo in the queue to 0 of the entry already processed but not
succeed by calling sig_clear(). This patch ensures the sig_clear()
to remove the entry fr
If process() failed and the signal remains in the queue, the most
possible reason is that the target thread already armed by another
signal and do not handle it yet. With this patch, to increase the
chance of handling it in the other threads, call yield() before
retrying process().
Addresses: http
Previously, the sig thread ran in THREAD_PRIORITY_HIGHEST priority.
This causes a critical delay in the signal handling in the main
thread if too many signals are received rapidly and the CPU is very
busy. In this case, most of the CPU time is allocated to the sig
thread, so the main thread cannot
On Dec 3 21:31, Takashi Yano wrote:
> On Tue, 3 Dec 2024 21:17:47 +0900
> Takashi Yano wrote:
> > On Mon, 2 Dec 2024 16:14:59 +0100
> > Corinna Vinschen wrote:
> > > On Nov 29 20:48, Takashi Yano wrote:
> > > > The queue is cleaned up by removing the entries having si_signo == 0
> > > > while proc
On Dec 3 21:36, Takashi Yano wrote:
> On Mon, 2 Dec 2024 15:25:54 +0100
> Corinna Vinschen wrote:
> > On Nov 29 20:58, Takashi Yano wrote:
> > > On Wed, 27 Nov 2024 17:53:53 +0100
> > > Corinna Vinschen wrote:
> > > Hmmm, just setting THREAD_PRIORITY_NORMAL might be appropriate.
> > > See v3 patch
On Dec 3 10:20, Christian Franke wrote:
> Brian Inglis wrote:
> > On 2024-12-02 11:28, ASSI wrote:
> > > Christian Franke writes:
> > > > + nice value sched_priority Windows priority class
> > > > + 12...19 16 IDLE_PRIORITY_CLASS
> > > > + 4...11 7...12
On Mon, 2 Dec 2024 16:18:15 +0100
Corinna Vinschen wrote:
> On Nov 29 20:59, Takashi Yano wrote:
> > Previously, the sig thread ran in THREAD_PRIORITY_HIGHEST priority.
> > This causes a critical delay in the signal handling in the main
> > thread if too many signals are received rapidly and the CP
On Mon, 2 Dec 2024 15:25:54 +0100
Corinna Vinschen wrote:
> On Nov 29 20:58, Takashi Yano wrote:
> > On Wed, 27 Nov 2024 17:53:53 +0100
> > Corinna Vinschen wrote:
> > Hmmm, just setting THREAD_PRIORITY_NORMAL might be appropriate.
> > See v3 patch.
> >
> > > The culprit of the behaviour you're se
On Tue, 3 Dec 2024 21:17:47 +0900
Takashi Yano wrote:
> On Mon, 2 Dec 2024 16:14:59 +0100
> Corinna Vinschen wrote:
> > On Nov 29 20:48, Takashi Yano wrote:
> > > The queue is cleaned up by removing the entries having si_signo == 0
> > > while processing the queued signals, however, sipacket::proce
On Mon, 2 Dec 2024 16:14:59 +0100
Corinna Vinschen wrote:
> On Nov 29 20:48, Takashi Yano wrote:
> > The queue is cleaned up by removing the entries having si_signo == 0
> > while processing the queued signals, however, sipacket::process() may
> > set si_signo in the queue to 0 of the entry already
GCC 15 enables `-std=gnu23` by default which breaks build of `newlib` and
`winsup` on old-style C function declarations. This patch changes the
declarations to ANSI style.diff --git a/winsup/cygwin/libc/fts.c b/winsup/cygwin/libc/fts.c
index 1826d2213..6f060e54e 100644
--- a/winsup/cygwin/libc/ft
On Dec 2 19:58, Christian Franke wrote:
> ASSI wrote:
> > Christian Franke writes:
> > > +nice value sched_priority Windows priority class
> > > + 12...19 16 IDLE_PRIORITY_CLASS
> > > + 4...11 7...12 BELOW_NORMAL_PRIORITY_CLASS
> > > + -43
Brian Inglis wrote:
On 2024-12-02 11:28, ASSI wrote:
Christian Franke writes:
+ nice value sched_priority Windows priority class
+ 12...19 16 IDLE_PRIORITY_CLASS
+ 4...11 7...12 BELOW_NORMAL_PRIORITY_CLASS
+ -43 13...18 NORMAL_P
24 matches
Mail list logo
