On Tue, 26 Nov 2024, Jeremy Drake via Cygwin-patches wrote:
> On Tue, 26 Nov 2024, Corinna Vinschen wrote:
>
> > Btw...
> >
> > We're doing this because nobody being able to debug ARM64 assembler came
> > up with a piece of code checking the ntdll assembler code to find the
> > address of the fast
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> Btw...
>
> We're doing this because nobody being able to debug ARM64 assembler came
> up with a piece of code checking the ntdll assembler code to find the
> address of the fast_cwd_pointer on ARM64.
>
> You seem to have the knowledge and the means to
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> On Nov 25 11:24, Jeremy Drake via Cygwin-patches wrote:
> > + switch (wincap.host_machine ())
> > + {
> > + case IMAGE_FILE_MACHINE_AMD64:
> > + n = stpcpy (buf, "-x64") - buf;
> > + break;
> > + case IMAGE_FILE_MACHINE_ARM6
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> On Nov 25 11:21, Jeremy Drake via Cygwin-patches wrote:
> > +extern const IMAGE_DOS_HEADER
> > +dosheader __asm__ ("__image_base__");
>
> On second thought, shouldn't we just use GetModuleHandle ("cygwin1.dll")
> instead of going asm here?
I was hopi
Btw...
On Nov 25 11:21, Jeremy Drake via Cygwin-patches wrote:
> @@ -4617,14 +4617,12 @@ find_fast_cwd_pointer ()
> static fcwd_access_t **
> find_fast_cwd ()
> {
> - USHORT emulated, hosted;
>fcwd_access_t **f_cwd_ptr;
>
> - /* First check if we're running in WOW64 on ARM64 emulating AM
On Nov 25 11:24, Jeremy Drake via Cygwin-patches wrote:
> 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
> mac
On Nov 25 11:21, Jeremy Drake via Cygwin-patches wrote:
> 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
On Nov 25 21:20, Christian Franke wrote:
> 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.
> > >
Previously, the retry flag was always set when pending_signal::pending()
was called. However, if the queue is empty sig thread tries to flush
the queue even though it is not necessary. With this patch, the retry
flag is set only if the queue is not empty.
Addresses: https://cygwin.com/pipermail/cy
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
This patch calls Sleep() in lock() in order to increase the chance
of being unlocked in other threads. The lock(), unlock() and locked()
are moved from sigfe.s to cygtls.h so that allows inline expansion.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 61522196c715
---
winsup/cygwin/release/3.5.5 | 4
1 file changed, 4 insertions(+)
diff --git a/winsup/cygwin/release/3.5.5 b/winsup/cygwin/release/3.5.5
index d91f2b92c..e7c0decbf 100644
--- a/winsup/cygwin/release/3.5.5
+++ b/winsup/cygwin/release/3.5.5
@@ -45,3 +45,7 @@ Fixes:
- Fix segfault in sigt
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
With the previous code, the queued signal is tried to resend only when
a new signal arrives or pending_signals::pending() is called.
With this patch, if the signal is queued and the retry flag is not set
and the new signal is not received yet, the sig thread tries to handle
the queued signal again.
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 the sig thread, but not is handled by the
main thread yet (sig_handle_tty_stop() not called yet), and if SIGCONT
is received, the sig t
Takashi Yano (7):
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
16 matches
Mail list logo
