Loading ...
Sorry, an error occurred while loading the content.

Re: Interrupting a python script

Expand Messages
  • Marc Weber
    ... Even if (I didn t check) the timer would not fire because no gtk event loop will be run as long as vim is executing python code ? What is happening
    Message 1 of 10 , Sep 5, 2013
    • 0 Attachment
      Excerpts from Ernie Rael's message of Thu Sep 05 19:30:37 +0200 2013:
      > If I saw things correctly, select is run under a timer.
      Even if (I didn't check) the timer would not fire because no gtk event
      loop will be run as long as vim is executing python code ?

      What is happening exactly?
      While VimL is running vim calls a "run gui event loop" occasionally, to
      found out that ctrl-c was pressed (otherwise you cannot abort viml).

      Why does this fail for python? You cannot tell pyton "let me run my
      event loop occasinally to find out whether ctrl-c was pressed", because
      you cannot patch the python interpreter implementetation.

      For this reason I think we need two threads: one for the event loop, one
      running python. the PyError function I talked about is thread safe (I
      looked it up)

      If we get started with this all, we can try to fix other issues as well.
      This will need da lot of:
      - work, dedication
      - support from the community (testing)
      - documenting the new ctrl-c behaviour

      If somebody knowing vim better than I do could comment on the "needs
      thread" thing - eg deny or acknowledege, then I'd know not doing the
      wrong thing.

      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ernie Rael
      ... OK, I went through the old emails again and see that now. ... Are you sure about that? Isn t there still a controlling tty? I m not certain and don t have
      Message 2 of 10 , Sep 8, 2013
      • 0 Attachment
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        ... No. If you use --nofork and if you press ctrl-c in the terminal you might be lucky. However this is not enough because - people start vim from menu -
        Message 3 of 10 , Sep 8, 2013
        • 0 Attachment
          > Are you sure about that?
          No. If you use --nofork and if you press ctrl-c in the terminal you
          might be lucky.

          However this is not enough because
          - people start vim from menu
          - people might not use --nofork

          Current implementation does not interrupt anything using but VimL even
          using --nofork (tested pyton and ruby)

          > Have you tried enabling SIGINT in gui mode?
          There is a problem: Its hard to know the pid unless you take notes
          upfront. Maybe you can send such a signal, but users are used to
          pressing "ctrl-c" in whatever window is active?

          > 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.
          A lot, but having nice async support is something we should strive for
          :(

          I cannot afford hacking on Vim for days at the moment. So this has to
          wait in any case unless somebody is willing to fund such work.

          I'd also like to see at least 5 people wanting this to be fixed.
          We're two now.

          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        Your message has been successfully submitted and would be delivered to recipients shortly.