Hi Marc, On Wed, Nov 20, 2024 at 8:55 AM Marc Culler <marc.cul...@gmail.com> wrote: > > > > On Wednesday, November 20, 2024 at 1:06:39 AM UTC-6 tobia...@gmx.de wrote: > > The new version of cysignals, released just a couple of hours ago, now builds > using Meson and works fine on Windows. > > > > @Marc, Nathan & collaborators: I've seen that CyPari has some > Windows-specific signal handling. Would be awesome if these changes could be > added to cysignals (if necessary and not done already) and then you could > perhaps use cysignals in Cypari. > > I don't understand what you are saying. When you say "works on Windows" do > you mean that the build works? I am certain that sig_on and sig_off do not > work on Windows if you have not added any Windows-specific signal handling.
You're right, there is no Windows-specific implementation of signal handling there, as I pointed out in the review of https://github.com/sagemath/cysignals/pull/207 > Also we *do* use cysignals in CyPari -- that is, we use our modified version > of cysignals, which works on Windows. Right, so it seems that merging your modifications into sagemath/cysignals would be a natural thing to do, then you could get rid of the modified version you're currently using. Best, Dima > > The Windows-specific signal handling is essential if you want to make sig_on > and sig_off work in Windows, and cysignals is what provides those functions. > > The core problem on Windows that must be solved to make sig_on and sig_off > work is this > (1) sig_on and sig_off use longjmp inside of a signal handler > (2) on Windows a signal handler runs in a separate thread and therefore has > its own stack. Consequently > setjmp and longjmp cannot be used in a signal handler on Windows. > > The way setjmp and longjmp work is that setjmp takes a snapshot of the main > execution stack which is saved in a global variable and longjmp restores the > state of the main execution stack to what it was at the time the snapshot was > taken. > > The way that sig_on and sig_off work is that sig_on installs some special > signal handlers and then calls setjmp. That should happen immediately before > calling some external library function, say from libpari. If that library > function produces a killer signal, say SIG_SEGV, then the special SIG_SEGV > signal handler calls longjmp to restore the state of the stack before the > library function was called. It then executes its own exit procedure which > prints a message about the segfault and exits cleanly. If the library > function executes with no signals then sig_off should be called immediately > to restore normal signal handling. Obviously if longjmp is called from a > thread which has a different main execution stack all hell will break loose. > > The trick that we use in the CyPari version of cysignals to avoid this > pitfall is that we exploit the fact that, in truth, there is one and only one > signal handler on Windows which *does* run on the main execution stack of the > process receiving the signal. That is the handler for SIG_FPE - floating > point exception (which usually does not terminate a process). To make this > work our special handler for, say, SIG_SEGV sets some global state and then > raises SIG_FPE. Our handler for SIG_FPE checks the global state to decide > whether the SIG_FPE is really a floating point exception or was raised by > some other signal handler. > > - Marc > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/sage-devel/843570bf-56a3-4223-a446-a43a615f5a83n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq2pc32LAkU_XH1w%3DDvommrQeO9RqtgVidnz8G%2B75SXa4w%40mail.gmail.com.
