On Thu, Jun 09, 2016 at 10:53:16PM +0200, Bram Moolenaar wrote:
>
> Danek Duvall wrote:
> > The thought I have was to do the classic thing where the signal handler
> > sets a global flag and returns immediately. For the majority of the cases
> > I've seen, the loop in RealWaitForChar is where the signal hits anyway, so
> > checking for that flag there would be easy, and it could call
> > preserve_exit() and exit quickly and sanely, even if it can't do a lot of
> > cleanup. The simple (and incomplete) attached patch works for my testcase.
> > Other places would be harder to handle, but maybe they don't happen enough
> > to be worth it.
>
> This might work better when actually waiting for a character, but it
> makes Vim completely ignore the signal when it's looping somewhere.
> Which would be the reason to send it a signal in the first place.
Vim already performs checks for interrupts ({fast,line}_breakcheck).
Having flags set for certain signals (including SIGINT) and checking
that instead of performing a select() every time those functions are
called would vastly improve the performance of places where those are
called in a relatively tight loop.
An example of this I've been meaning to bring up is:
$ ctags -R /usr/include
$ vim
:echo taglist('a')
This takes minutes to complete, nearly all of which is spent in select()
calls.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--
--
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/d/optout.
