On Tuesday, September 3, 2013 1:53:31 PM UTC-5, kans wrote:
> On Tuesday, September 3, 2013 9:04:40 AM UTC-7, Ben Fritz wrote:
> > On Sunday, September 1, 2013 8:42:25 PM UTC-5, Geoff Greer wrote:
> > > This patch adds asynchronous functions to vimscript. If you want to
> > > perform an action in 700ms, simply:
> > >
> > > let timeout_id = settimeout(700, 'echo("hello")')
> > >
> > > To cancel the timeout before it's fired:
> > >
> > > canceltimeout(timeout_id)
> > >
> > > setinterval() also returns an id that can be used with canceltimeout.
> > >
> > > The reason for this patch is simple: asynchronous functionality is needed
> > > to implement real-time collaborative editing in Vim. This is one of the
> > > most voted-for features (see http://www.vim.org/sponsor/vote_results.php).
> > >
> > > Along with Matt Kaniaris, I founded Floobits to build real-time
> > > collaboration into every editor. We wrote a plugin for Vim, but we had to
> > > use hacks to get async behavior (abusing feedkeys or client-server).
> > > These methods had side-effects such as breaking leaderkeys or other
> > > shortcuts. After a lot of experimenting, we decided to try patching Vim.
> > >
> > > Since Vim is character-driven, we had to munge some low-level input
> > > functions to get the desired behavior. We changed gui_wait_for_chars()
> > > and mch_inchar() so that call_timeouts() is run every ticktime
> > > milliseconds. The default ticktime is 100ms.
> > >
> > > This patch isn't finished yet, but it works on unix-based OSes. If the
> > > reaction is positive, our intention is to change mch_inchar() (or
> > > something similar) in other OS-specific files. That will get async
> > > functions working for everyone.
> > >
> > > Even if our patch isn't the best approach, we'd love to help get async
> > > functions in Vim. Doing so will open the door to a lot of cool plugins.
> > >
> > > Oh, and this is the first time either myself or Matt have submitted a
> > > patch to Vim, so please be gentle.
> > >
> > > Sincerely,
> > >
> > > Geoff Greer
> >
> > Forgive me if I'm wrong, I didn't spend more than a few minutes looking
> > over the patch.
> >
> > It looks like this is not really "asynchronous" behavior, but rather adding
> > a timer-like hook into the main loop. Pro: no worries about thread safety,
> > race conditions, etc. Con: if the function called by the timer event takes
> > a long time, Vim hangs until it's done.
> >
> > If I'm correct, and this gets included, the help will need to be very
> > explicit about making sure to limit the time taken by the function called!
> > And there should definitely be a way to interrupt the action.
>
> Ben,
>
> You are correct in that we added a timer to the main loop. Looking over the
> code once again, I think we should have altered the calls to select/poll
> instead, but lets discuss the practical effect of this patch since we can
> work out the details some time later.
>
I like the practical implications of being able to respond to a timer event in
a plugin. Polling is useful for many, many purposes, and doing it by shelling
out and calling back with --remote calls is awkward at best.
> Async does not imply parallelism nor safety- it only provides the illusion of
> concurrency. Idle cpu time spent waiting is instead used to perform some
> other task. Async frameworks make no such guarantee that every call not
> block the event loop; it is incumbent upon the programmer to ensure that the
> event loop is not blocked indefinitely. This is the definition and standard
> interface of async programming for every popular framework I can think of
> that lives in a scripting language- JavaScript, nodejs, twisted, event
> machine, and luvit.
>
I'm more familiar with C/C++/Java, and even shell scripting, where "async"
means it doesn't block the main program flow, as wikipedia says on
http://en.wikipedia.org/wiki/Asynchrony: "Asynchronous actions are actions
executed in a non-blocking scheme, allowing the main program flow to continue
processing."
So, in my mind..."async" normally implies parallelism.
You've created an interface that is probably close enough, if developers are
careful not to allow their timer callbacks to take too long, or use them to
spawn and monitor a truly async process via the shell or python or whatever.
The nice thing is that you thus avoid the problem of concurrent access/thread
safety, because you've not used multiple threads or processes at all. The
not-so-nice thing is the inability to call long-running worker functions with
your interface.
> The current alternative in Vim is to block forever, or worse yet, not write
> useful software because it is impossible to do so as a Vim plugin. With a
> proper settimeout, plugins have the option of returning control to the main
> loop and checking in latter.
I agree, we need something. That concurrent editing thing looked really neat!
And doubtless it would be much more robust/easier to maintain with timer events
in Vim.
> I'd suggest a settimeout on the settimeouts is not needed; plugins which
> cause too much trouble will either be fixed or uninstalled.
Possibly; but I'd rather not find the bug in the plugin by losing a lot of work
when my Vim goes into an infinite loop that can't be interrupted.
--
--
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.
