csighandler3: try a fallback interpreter if none in TLS #22530
Conversation
If an external library, possibly loaded by an XS module, creates a thread, perl has no control over this thread, nor does it create an interpreter for that thread, so if a signal is delivered to that thread my_perl would be NULL, and we would crash trying to safely deliver the signal. To avoid that uses the saved main interpreter pointer instead. Since trying to unsafe deliver the signal to the handler from the wrong thread would result in races on the interpreter's data structures I chose not to direct deliver unsafe signals. Accessing PL_psig_pend[] from the wrong thread isn't great, but to ensure safe handling of that we'd need lockless atomics, which we don't have access to from C99 (and aren't required in C11). Fixes Perl#22487
|
I'm wondering if a |
Maybe, but Win32 already does something like my patch, Ctrl-C events are delivered in a separate thread, and PERL_GET_SIG_CONTEXT aka win32_signal_context() sets the the context for the current thread from PL_curinterp and expects Perl_csighandler3 to deal with it. Right now I don't see a direct way for us to get the main thread ID/handle. That's something I'd need to add to |
|
@tonycoz Has anyone ever tried taking a shot at implementing https://en.wikipedia.org/wiki/Dekker%27s_algorithm / spin locks? CTRL-C rarely but still randomly crashing on blead to this day. |
|
CTRL-C on windows perl blead still often crashes, but I have plans to fix it. Makes me wonder if |
|
On Fri, Oct 18, 2024 at 06:47:08AM -0700, bulk88 wrote:
Makes me wonder if ```Perl_croak_no_mem()``` should be PP trapable or not?
What do you mean by "PP trapable"?
…--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in "Star Trek" #9
|
|
Was that backtrace with a perl signal handler set for SIGINT? That looks like it's calling the emulation done when no signal handler is set, which while a problem, is a different problem. (sig_terminate() should probably be calling _write() or maybe WriteFile(), not Perl_warn()). |
Here is file "c.pl", please RUN ON 32B perl ONLY to hit 2GB limit quickly. Why did my PP I did try above code with PP eval{} block, not string, and NO YOU CAN NOT PP eval{} trap and resume execution after perl's OOM C/XS croak, but you can run PLENTY of unlimited wall time, unlimited CPU and unlimited amounts of P5 PP source code, AFTER perl's OOM C/XS croak's function call executed, as I showed above. And while that DESTROY sub is simple, a production app/module, could try writing JSON to disk in a DESTROY sub after The SQL "meta handle" implemented in pure perl, XS/C, or as an IPC IP socket. Doesn't matter, just massive I/O and massive amount of pure perl statements (PP op count) will now execute in that DESTROY {} sub. Maybe even calling For linux people, assume |
|
I see only 1.5 solutions to signals/Win32 CTRL-C/signal CB fires on a random no-``my_perl``` thread from OS thread pool problem. Step 1, from random thread Step 3A if suspended thread CPU execution pointer in official my_perl tid, is not at the kernel mode call gate, we could, medium danger, reregister Weird proposal, check Other idea, random OS thread pool signal/event callback thread, sets If 15/30 ms timer expires in thread pool thread, with no answer from my_perl in official TID, do a libc only no perlIO Another step 3A, if timer expires in thread pool thread, ask OS for cpu usage time on official my_perl TID, if it didn't change, Win NT Kernel after Vista or after Win 8, or Win 10, has some drama with CPU usage I've read about, and I think my unsubmitted code on another FOSS project hit it, Basically different NUMA clusters cache or keep thread CPU time in a per-core or per NUMA cluster, or per 64 core unit, and dont update the root CPU core's (aka Kernel's global struct) for multiple 15 ms quantums or like 100 ms, when the granularity is supposed to 15 ms to avoid lock contention. Plus a couple kernel optimizations, or certain driver and I/O calls, since those drivers "burn CPU" or force assign CPU time to the user mode thread for accounting reasons, those kernel calls don't update the thread cpu usage, only actually switching threads and swapping page tables to another process, triggers an update of the global struct with thread CPU time. This might be an edge case tho for perl signal reasons that doesn't matter 15 ms or 100 ms. Both are instant to human eye. (legacy Win NT Kernel API problems from 1980s, thread to core pinning API, accepts a 64 bit MASK, not an var len array of core |
From what I can tell that's the default handler that emulates default SIGINT behaviour. The problem is we call Perl_warn() from a what is effectively a signal thrown in a fresh thread - it's even less safe than Perl's old unsafe signals on POSIX-like systems (ie. very not safe.) It populates THX with the main thread's interpreter which is still running at this point, and unlike this PR, does some slightly to very complex things with the state of the interpreter (slightly: allocates new SVs, very: if STDERR is tied, invoke it's PRINT callback, or if If |
That could be set during initialization, right? That doesn't sound like much of a problem? |
For anyone wondering this is #13596 |
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
This is only done for pthreads, Win32 already uses something like my suggestion from Perl#22530 and unlike POSIX doesn't have a way to asynchronously interrupt a thread that I'm aware of. It's also complicated by pseudo-processes. Fixes Perl#22487
If an external library, possibly loaded by an XS module, creates a thread, perl has no control over this thread, nor does it create an interpreter for that thread, so if a signal is delivered to that thread my_perl would be NULL, and we would crash trying to safely deliver the signal.
To avoid that uses the saved main interpreter pointer instead.
Since trying to unsafe deliver the signal to the handler from the wrong thread would result in races on the interpreter's data structures I chose not to direct deliver unsafe signals.
Accessing PL_psig_pend[] from the wrong thread isn't great, but to ensure safe handling of that we'd need lockless atomics, which we don't have access to from C99 (and aren't required in C11).
Fixes #22487