[slim-vim] More details on the socket crash bug

[Brad Beveridge]

On 15/06/06, Larry Clapp <larry at theclapp.org> wrote:
> On Tue, Jun 13, 2006 at 12:39:39PM -0700, Brad Beveridge wrote:
> > On 13/06/06, Larry Clapp <larry at theclapp.org> wrote:
> > > I think it goes *something* like this
> > >
> > >   vim-1: write to socket
> > >   vim-2: read from socket; echo what it read
> > >   vim-1: read what vim-2 echoed to it
> > >   [ repeat above 3 lines an unknown # of times, then ... ]
> > >
> > >   vim-1: write to socket
> > >   vim-2: read from socket; echo what it read
> > >     vim-1: before write call finished, vim main loop sees data on the
> > >           incoming socket while it's doing an append, and calls the
> > >           ecl network read callback
> > >   [ This happens a few times, and eventually something goes squirrelly ]
> > >
> > That is pretty much the way I am leaning right now too.  But I don't
> > see how it can happen, as far as I can tell the mainloop should
> > block on various file descriptors and be totally single threaded.
> > So how does the mainloop run before ECL has finised running its
> > code?
>
> I figured somewhere in the "append to buffer" code.
>
> > I've asked about the async patch on the Vim list, and I've posted to
> > the ECL list as well.
>
> I saw the one on the ECL list.  (I'm on the ECL list, too.)
>
> > Juan, the maintainer of ECL has expressed more than just a casual
> > interest, so it'll be nice to have him take a look.
> >  I think he'd quite like to see ECL embedded in an editor.
>
> It's funny; Eirik and I have mentioned Vim+ECL on the ECL list before,
> but Juan's ears didn't seem to perk up then.  Maybe the OS X
> connection made the difference.  :)
>
> -- L
>
> _______________________________________________
> slim-vim mailing list
> slim-vim at lispniks.com
> http://www.lispniks.com/mailman/listinfo/slim-vim
>

My thoughts from tonight's debugging:
Although Vim is only single threaded, almost any chunk of Vim code can
and will call RealWaitForChar, which is where our networking callbacks
happen.  Code that runs in ECL can and will end up calling
RealWaitForChar, which may trigger callbacks to ECL.  I still think
this is our problem, and I have caught it in this state before.
However, I've tried placing crude mutexes around bits and pieces, I
still see the problem and RealWaitForChar is not appearing more than
once in my call stack.
Random thought - has anybody checked to see if garbage collection is
working properly?

Cheers
Brad