[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Win32 CTRL-C handling (Was: interrupt handing and the GUI (bug #3767

From: Michael Goffioul
Subject: Re: Win32 CTRL-C handling (Was: interrupt handing and the GUI (bug #37672))
Date: Mon, 18 Nov 2013 17:58:43 -0500

On Mon, Nov 18, 2013 at 10:50 AM, Michael Goffioul <address@hidden> wrote:
One main issue I'd like to raise and discuss is the interaction with readline. Basically when you combine octave (using gnulib), readline (not using gnulib) and the fact that Win32 does not have siglongjmp, you start having conflicting situations.

Typically, readline installs its own SIGINT handler, but also store the previous handler for later use. During SIGINT handling, it does some internal clean-up, restore the previous handler, than "raise(SIGINT)" to execute the previous handler.

OTOH, octave uses gnulib. The gnulib's signal handling is along those lines: block the signal, execute the handler, unblock the signal. If the signal handler performs a longjmp, the signal will stay in "blocked" state (in gnulib, this translates into having a dummy handler that does nothing). Now the problem is that on the next run of readline, the stored handler will be the gnulib's dummy one, and CTRL-C will end up being ignored while being in readline loop. This does not happen on platforms having sigsetjmp/siglongjmp, or more generally on POSIX platforms.

I've worked around that issue by installing octave_interrupt_hook and make sure SIGINT is handled after an interrupt. Another way, which I tested, is to disable signal handling in readline by setting rl_catch_signals to 0, but I'm not sure to what extend this is a problem in readline itself.
Scrap that, it didn't work. It appears that gnulib is keeping internal/static states about signal handlers, which is not really compatible with readline making direct calls to the "signal" function from windows runtime DLL.

I ended up disabling signals in readline. The attached path works for me in GUI and CLI. Although as explained earlier, CTRL-C in CLI mode doesn't work as expected when in readline, because the key sequence is reported in the input buffer, not as a signal.

It would nice if someone can test it in MinGW.


Attachment: win32-ctrl-c-2.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]