On Thursday, February 20, 2014 12:50:13 AM UTC+4, Juan Campa wrote:
> On Wednesday, January 15, 2014 9:44:24 AM UTC-5, Ben Fritz wrote:
> > I thought the idea of this patch, was to allow background threads to send
> > Vim a message, that says "when you get a chance, run function X". Then, at
> > some later point in time, when Vim is not busy, it will run function X *IN
> > THE MAIN THREAD*. Thus there should be no conflict between the deferred
> > function and the main thread. Am I correct in this?
> >
> > If so, plugin authors must simply ensure that function X is threadsafe with
> > the background functions in the same thread. This probably means making
> > sure that the background thread is DONE with whatever data function X will
> > access, until function X can run and is done with that data.
>
> Hey guys, I hope I'm not late for this conversation.
>
> I've implemented a method to call deferred functions in the main thread from
> a another thread (I'm using python's threading library for that). It works by
> spawning another instance of vim from the thread to send a command to the
> current instance (i.e. vim --servername <this instance's servername>
> --remote-expr <function to call>) so main thread ends up calling the
> specified function when it gets the chance.
Not when it gets the chance. Check out the following: make server run `while 1
| sleep 1 | endwhile` and send that expression (I tested it on `input("abc")`).
You will see that despite something being run received expression will still be
processed. Though I am unable to reproduce this I remember @MarcWeber
complaining about random crashes when using this feature on daily basis. Not
too likely but still happening.
>
> Now, before you burn me alive, I now there's a lot of unnecessary overhead in
> this method ("spawning another Vim? Are you insane!?") but it's working
> surprisingly well for the use cases I have, i.e. it's all transparent for the
> user and I can't notice any performance hits.
>
> My point is that I suspect (with high levels of confidence) that this same
> mechanism could be leveraged but without having to spawn a separate vim
> instance. This would require minimal source changes and it should just work
> because it would use the same mechanisms that are already working rock solid.
>
> Let me know what do you think.
--
--
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.
