Brad Beveridge wrote: > Hello all, I am involved in a project that has embedded ECL > (http://ecls.sourceforge.net/), a Lisp interpreter into Vim. Our end > goal for the project involves having Lisp code inside of Vim respond > to incoming data from a socket, so we also have a patch that allows us > to register callbacks that will be triggered when we receive data on a > file descriptor. > The code for this is here http://theclapp.org/repos/. The async > callback patch only really works for GTK and console I think. > Basically all the patch does is add a few more file descriptors to > poll/select on during Vim's read_char, if the appropriate descriptor > is triggered then we get a callback to Lisp. > > The callbacks all appear to work fine, for example you can setup a > listening socket in Vim and have data output to a Vim buffer without > any problems. But there is a bug. Lets assume that we have a server > that simply echoes back data, and a client that sends data. > Data flow is something like: > (CLIENT) Embedded Lisp script sends data > (SERVER) Echoes data back > (CLIENT) Still sending data, there is also pending data coming back > from the server > (CLIENT) Finishes sending data, next time through the read_char loop > should trigger call back which will read data out from the socket. > > However, the CLIENT side crashes in this scenario, it appears to crash > inside the Lisp interpreter. I suspect that somehow the last two > phases above are overlapping, and the interpreter is being re-entered, > which I don't think it supports. However, I don't see how this can be > happening - as far as I am aware Vim is totally single threaded (at > least *nix console builds), so the behaviour should be deterministic, > the data will finish sending, continue out to the main loop and then > trigger the callback. > > I know it is a lot to ask for help on such a modified Vim, but this is > really starting to get me down. I would really appreciate any > thoughts about what might be going on, or how to debug this.
Although the main Vim loop is on thread that waits for the next thing to do, the GUI may involve asynchronous events. Vim generally handles GUI events by putting characters in the input queue and waking up the loop that is waiting for input. There are a few exceptions, e.g. to handle scrollbars when the main loop can't be waked up. I can't guess what happens for you. Adding a few printf() calls might reveal any recursive calls to functions that should not be called recursively. -- Two fish in a tank. One says to the other: "Do you know how to drive this thing?" /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
