On 9/3/2013 6:34 PM, Marc Weber wrote:
This is my message you've been looking for:
https://groups.google.com/forum/#!searchin/vim_dev/Ruby$20abort$20vim$20marc/vim_dev/irITPpKnTP8/Osl0AHJUH60J
You're looking for PySetInterrupt();
For ruby there is an equivalent.
Fixing it would require diving into the signal handling, and I didn't
understand it - either it has to be refactored and defined well when
what should happen or ...
My comments have been ill-informed. I just took a brief look at the vim
code and read the threads you point out; thanks. The following comments
are more in line with the reality of the vim code (but may still be off
base). I'm assuming that vim/python runs in the same thread; when python
executes, vim does not executing until the python call returns.
Of course vim must "normally" run in RAW mode so that it sees all the
keyboard action, and so can not usually get interrupts. Vim turns on
interrupts when it executes an external command. I think the following
approach requires minimal changes to vim's structure and still handles
the issue.
- the python interface enables interrupts when it executes python,
something like mch_call_shell with option SHELL_COOKED.
- the SIGINT handler informs python to stop
The SIGINT handler is already minimal (considering only os_unix.c), it
could be changed to something like:
signal(SIGINT, (RETSIGTYPE (*)())catch_sigint);
#if PYTHON_SUPPORT
if(pthon_busy)
do_python_interrupt_stuff();
#endif
got_int = TRUE;
SIGRETURN;
The above is only for discussion (not for compilation). This always
sets got_int even if python_busy, should be OK and might be safest. The
check of python_busy in this function is for clarity; efficiency is not
an issue in this function so could simply call
python_handle_interrupt_signal() that check state if/as needed (it may
be that PySetInterrupt. can be invoked even if the python interpreter is
not running).
There may be subtleties in enabling interrupts before calling python,
but it might be as simple as
int tmode = cur_tmode;
settmode(TMODE_COOK);
execute_python_stuff_as_usual_and_set_the_python_busy_flag();
settmode(tmode); /* may be this is always TMODE_RAW */
If you'd like to collaborate on fixing this let me know.
I've never contributed to vim, and only occasionally use python (never
with vim). I'm not a good candidate. But I really enjoy considering real
time issues.
Note that this does not consider the broader questions and issues around
multi-threading and vim. The intent is to fit a simple solution into the
existing structures.
-ernie
For me alone it'll be too much work. Who else would love to join and
help fixing this?
The main problem is that everything is based on a huge hack:
gui_process_events which gets called even when viml is running, so that
ctrl-c can be "looked ahead" and viml can be aborted.
This gui_process_events like functions has side effects which I think it
should not have, see thread linked above about resize which is not used
often enough to really care about.
Which is the corret way to fix this? Have a separate gtk thread which
gets keyboard input, processes it, and when finding a ctrl-c sets
PySetInterrupt causing python to stop (running in a different thread).
And that's where/why I stopped - I had the feeling that fixing this
would require adding multi threading support or such - thus rewriting
much gui code. I personally think its the future - but I cannot do it
alone. Does anybody have different views / ideas / solutions ?
Marc Weber
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
