[slim-vim] design discussion: network callbacks & recursion

[Larry Clapp]

On Fri, Jul 28, 2006 at 11:11:45AM -0700, Brad Beveridge wrote:
> On 28/07/06, Larry Clapp <larry at theclapp.org> wrote:
> > While adding Win32 socket support to Vim, I've seen that Windows
> > can call the network IO handler callback before the previous
> > callback has finished, i.e. indirectly recursively.  The Netbeans
> > interface, on which Jim based the network_io interface, shows that
> > this can happen on X11/Athena, Motif, and gtk platforms, too.
> > This causes problems if you don't account for it.
> So the GUI based interfaces are actually asynchronous, rather than
> the psuedo-async that we do for the console?

I don't think so.  I think when you do stuff involving Vim functions,
the way Vim implements mappings and so forth, it calls the main input
function, which also (or maybe by definition) reads the
Windows/X11/Gtk event stream -- and might call your network callback.

> > Thoughts / answers / comments / criticism?
> >
> I all sounds pretty good and sensible to me.  I'm a tad concerned
> about how well Slim-vim would handle partial messages - I suspect
> that it wouldn't.

It can do so pretty easily; it only took a few extra lines.  But I'll
take that out if I get the blocking read working in Windows, too.

If I can't get blocking read to work under Windows, then we'll either
have to do busy-wait (sleep for a hundredth of a second and check
again), or deal with incomplete messages.  As mentioned, that was
easy.

> We may need a tad more handling to ensure that only whole messages
> are pulled from the Gray stream.  Of course, we've survived so far,
> which means either:
> 1) We only ever get whole messages to work with from Swank

Yes: right now the X11/Gtk versions do the blocking read mentioned
above.

> I'm happy with what you proposed.  I've had almost no time to geek
> out lately, so I've done pretty much no Slim-vim work.  Perhaps this
> weekend.

No worries.  Take your time.  :)

-- L