octave-maintainers
[Top][All Lists]
Advanced

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

Re: interrupt handing and the GUI (bug #37672)


From: Thorsten Liebig
Subject: Re: interrupt handing and the GUI (bug #37672)
Date: Wed, 13 Nov 2013 10:24:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

> I checked in a series of changesets that appear to fix the problem on
> systems with pthreads.
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/a38cee8f0a9b
>   http://hg.savannah.gnu.org/hgweb/octave/rev/b6d07dd90f3d
>   http://hg.savannah.gnu.org/hgweb/octave/rev/5c3f22dd0bbb
>   http://hg.savannah.gnu.org/hgweb/octave/rev/2a4acd6548c6
>   http://hg.savannah.gnu.org/hgweb/octave/rev/b5bf26a054bd
>
> It works on my Debian system.  I ended up using both pthread_sigmask
> to block SIGINT in all threads and then unblock it in the thread that
> is running the Octave interpreter.  Then I also used pthread_kill to
> direct the SIGINT signal to the thread that is running the
> interpreter.  That seemed to work.  Using only pthread_kill was not
> enough because it's possible for SIGINT to be generated in other ways
> and bad things can happen if it is delivered to any thread other than
> the one running the interpreter.
>
> The signals are now sent from some functions in a new class in
> libgui/src/thread-manager.cc.
>
> The implementation for Unix uses the pthread_sigmask and pthread_kill
> functions.
>
> The implementation for Windows is still calling "::raise (SIGINT)".  I
> tried using "GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0)" but that
> still crashes Octave if it is expecting to be able to longjmp out of
> the signal handler back to the most recent "safe" location.  I don't
> know how to fix this problem yet.  If anyone has a clue, help would be
> most appreciated.
>
> jwe
>
>

I'm going to test your changes.
But one more remark on Windows:
I just tried it again on an old mxe-build from Mai.
With version 3.7.5 the Octave GUI reacted normal to CTRL+C while on Linux it 
never did.
I reported that here: https://savannah.gnu.org/bugs/?37672#comment1
But at some point it stopped working and started behaving like the Linux 
version...
Maybe this help? Maybe you can find out how and why it worked in 3.7.5 in 
Windows??

If you need more infos, please let me know...

regards
THorsten


reply via email to

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