On 9/5/2013 10:28 AM, Marc Weber wrote:
I already have patched the interrupt stuff, and it works for the
console,
OK, I went through the old emails again and see that now.
but it still does not work for gui, because there is no
terminal sending SIGINT !
Are you sure about that? Isn't there still a controlling tty? I'm not
certain and don't have a unix system to test with. I thought the big
issue was the unreliability of signals in a typical gui environment.
This may not be as much of an issue with vim partly because it looks
like /vim doesn't use the event loop/ and PySetInterrupt() should be
async safe (IIUC); vim only picks up events when it knows there are
events to pick up, it doesn't hang in the event loop.
Have you tried enabling SIGINT in gui mode? This isn't a general
solution for the various problems with the current model, but it might
fix the python hang issue.
BTW, there's an interesting page on "X and signals"
http://www.eng.cam.ac.uk/help/tpl/graphics/X/signals.html
That's why I'm talking about adding multiple threads.
Certainly seems the right direction.
We could also get rid of all the resize issues inerrupting viml for
loops and so on.
After a quick look I'd aim for introducing USE_INPUT_THREAD define and
introduce a lock for the input_buffer and maybe of few other related
data structures; the lock is used in the add_to_input_buf(),
get_input_buf() and related methods. The input thread would hang in the
X event loop. Protecting the input buffer takes care of the key events;
there may be other events that can be put into the input queue. Some of
the other events are directly executed; a strategy is needed for these.
One possibility would be to have a second queue (maybe a priority Q) for
directly executed events. It might be useful to have some flags such as
ctrl_c_input.
In the vim thread have something like
gui_mch_update(void)
{
if(ctrl_c_input) {
got_int = TRUE;
ctrl_c_input = FALSE;
}
if(other_events_to_handle)
handle_other_events(); /* (in gui.c?) resize, menu, ... */
}
I don't think there is a reason that the input characters would only be
made visible to the vim thread, in gui_mch_update(), but I guess that's
possible.
Though conceptually simple (?), things are spread out and there are
certainly other things to look out for. I don't have any feel for how
much work such a change would be.
I'm assuming that output would continue to be in the vim thread.
To start with, only a single gui (the most commonly used I would hope)
needs to be ported. I suspect that the rest would follow quickly. I
usually like to start by getting something that works; after that there
could probably be simplifications of various areas.
Since I'm familiar with neither vim or X code (other than looking
through vim over the last week), the first thing I'd ask is if this
makes any sense at all. Someone familiar with gui programming might
suggest a much better, or more precise, approach.
-ernie
However it would be a lot of work probably *and* we need the community
to help testing.
Who would test?
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.
