Thiago, I would love this to work and I thank you for your effort, but I'm quite doubtful that vgetc can be safely run in a background thread. It simply does too much work. Just to pick one example, it appears to be responsible for blinking the GUI cursor while it's waiting, which will obviously conflict with any screen updates the main thread is doing. I've built your fork with TSan[1] enabled and run snake.vim and it complains of many other race conditions. I can send you the log if you're interested but I would suggest using TSan yourself.
Best, Ash [1] TSan: http://code.google.com/p/thread-sanitizer On Wednesday, 4 December 2013 20:45:35 UTC, Thiago Arruda wrote: > This patch implements the concept suggested in this > > post: https://groups.google.com/forum/#!topic/vim_dev/lylNU4Na2Nk > > > > Heres a simple explanation of whats going on: > > > > - A frozen 'background' thread is started at the beginning of the program. > > - At every iteration, the main_loop function will wake that thread to collect > > user input, and then will wait for a message > > - The background thread will block until the user interacts with vim, then it > > will put a message in the queue, and block until it receives another signal > > from the main thread. > > - When a message is put in the queue, the main_loop function unblocks, > > processing > > the message and continuing the loop. > > > > The reason for going through all this message queue trouble is simple: It > > enables vim to work and synchronize with multiple threads, which is a feature > > missed by many vim users and plugin authors :) > > > > For now the message queue only understands two types of messages: User input > > and deferred execution of functions. > > > > The simplest case of deferred execution is implemented by the 'defer' > function, > > which accepts a function name to execute on the next message loop iteration. > All > > this function does is put a message in the queue, and since the queue is > > thread-safe, this function can be used by other threads, started by python for > > example. I've written a simple python plugin which illustrates usage: > > http://pastebin.com/V9VzH0zU > > > > If youre gonna try this patch be sure to regenerate the configure script: > > (cd src && make autoconf). > > > > This is just a proof-of-concept and I have posted it only for review by > > Bram and other devs. I'm sure there are better options to some of the > > decisions took and I'm still very unfamiliar with the codebase. > > > > Here are the problems I could identify and could use help fixing: > > > > - Test 94 fails > > - gVim freezes at startup. I didnt dig much into this problem but its probably > > easy to fix since vim treats input from the gui in the same manner as input > > from the terminal. > > - I couldn't get the screen to update when running the function set by > 'defer'. > > In the vimscript demo you will notice that keys must be pressed to see the > > updates done by the background python thread. I've tried calling > > 'update_screen(0)' but it just didnt work, probably theres some > > check/validation to see if the user typed something before doing the actual > > update. > > > > I've done my best to modify as little as possible of the existing code. Anyone > > who reads the patch will notice that while this patch introduces a new module, > > not many changes were done. In fact the message_loop is implemented as a > > compile-time feature, to ensure that vim will continue to work on systems > > without pthreads. > > > > I'd like to finish this post by exposing some of the benefits of refactoring > > vim's design around a message-loop. > > > > - Plugins written in extension languages(python, ruby, perl...) could make > > use of threading for long running tasks and call vim back when done. > > > > - Introduce async versions of the builtin functions that can block the UI. > > > > For example, we could easily create the 'globAsync' and 'systemAsync' > > functions that would both accept a function name as last argument. These > > 'async' versions of the builtin functions would do their work in non-ui > > threads, which would periodically post messages with partially calculated > > data to be passed to the callbacks. > > > > Two widely used plugins could greatly benefit from this: Syntastic and CtrlP > > could collect compiler output and globbed filenames in a very efficient > > manner. > > > > - Better code organization. All kinds of events(signals, mouse or keyboard) > > could be modeled as specialized messages in the loop > > > > - Bring another level of extensibility to vim: > > - Terminal emulators in buffers > > - IDE-like capabilities > > - Write whole applications on top of vim > > Some may look down upon having these features in a text editor, but notice > > that these are provided by plugins, and wont affect the size or speed of > > a vim default installation. > > Vim may not provide an operating system but it certainly can provide a > tiny > > framework to build one! > > > > - Bigger community. If vim can do more then it will attract more developers. > > > > Thats it for now, anyone is welcome to work on this patch, just comment, send > > patches or raise issues at: https://github.com/tarruda/vim/tree/event-loop > > --- > > Filelist | 2 + > > runtime/doc/eval.txt | 3 + > > runtime/doc/various.txt | 1 + > > src/Makefile | 5 ++ > > src/config.h.in | 3 + > > src/configure.in | 17 +++- > > src/eval.c | 25 ++++++ > > src/getchar.c | 8 +- > > src/globals.h | 5 ++ > > src/main.c | 51 +++++++++++ > > src/message_queue.c | 226 > +++++++++++++++++++++++++++++++++++++++++++++++ > > src/message_queue.h | 34 +++++++ > > src/version.c | 5 ++ > > src/vim.h | 4 + > > 14 files changed, 384 insertions(+), 5 deletions(-) > > create mode 100644 src/message_queue.c > > create mode 100644 src/message_queue.h -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
